การแยกวิเคราะห์ส่วนหัวของส่วนขยาย IPv6 ที่มีส่วนขยายที่ไม่รู้จัก


113

ฉันกำลังเขียน net filter ที่ง่ายมากและไปที่ที่ฉันต้องการแยกวิเคราะห์ส่วนหัว IPv6 เพื่อจับคู่สิ่งต่างๆเช่นประเภท ICMPv6 หมายเลขพอร์ต TCP / UDP เป็นต้น

ดังนั้นฉันกำลังอ่านเกี่ยวกับรูปแบบแพ็กเก็ต IPv6ในเชิงลึกและฉันก็ชอบ ... อืม ... ฉันต้องอ่านซ้ำแล้วซ้ำอีกเพื่อให้แน่ใจว่าฉันอ่านถูกต้องจริงๆ สำหรับฉันแล้วดูเหมือนว่าคุณต้องเริ่มต้นด้วยส่วนหัวคงที่ 40 ไบต์และดูที่ฟิลด์ส่วนหัวถัดไป จากนั้นคุณต้องดูที่ฟิลด์ส่วนหัวถัดไปของส่วนหัวถัดไปและอื่น ๆ เช่นรายการที่เชื่อมโยงจนกว่าคุณจะไปถึงจุดสิ้นสุด หากมีน้ำหนักบรรทุกก็จะตามมา

ปัญหาคือไม่มีฟิลด์ความยาวในส่วนหัวคงที่หรือส่วนหัวส่วนขยาย คุณต้องมีตารางประเภทส่วนหัวของส่วนขยายและขนาดเพื่อให้คุณสามารถไล่รายการที่เชื่อมโยงนี้ไปจนสุด

สิ่งนี้ทำให้ฉันรู้สึกแปลก ๆ หรืออาจจะเป็นกระต่ายก็ได้ จะเกิดอะไรขึ้นหากฉันพบประเภทส่วนหัวของส่วนขยายที่ไม่รู้จัก ฉันจะทำอย่างไร? ฉันไม่รู้ความยาวของมัน ฉันเดาว่าฉันต้องโยนแพ็กเก็ตออกและบล็อกเนื่องจากในตัวกรองเน็ตที่อนุญาตให้แพ็กเก็ตผ่านจะทำให้ผู้โจมตีสามารถหลบเลี่ยงตัวกรองเน็ตได้โดยรวมประเภทส่วนหัวปลอม แต่นั่นหมายความว่าหากมีการขยายโปรโตคอลออกไปซอฟต์แวร์แยกวิเคราะห์ส่วนหัว IPv6 ทุกชิ้นที่เคยเขียนจะต้องได้รับการอัปเดตพร้อมกันหากจะใช้ส่วนขยายใหม่

ดังนั้นฉันจะแยกวิเคราะห์ส่วนหัว IPv6 ได้อย่างไรหากฉันไม่รู้ว่าส่วนขยายที่ใช้อยู่ ฉันจะข้ามส่วนหัวของส่วนขยายที่ไม่รู้จักได้อย่างไรเนื่องจากฉันไม่รู้ความยาว


10
จากคำถามนี้ดูเหมือนว่าฉันไม่ได้โง่และใช่ฉันกำลังอ่านสิ่งนี้ถูกต้อง: (ในโลกแห่งความเป็นจริง) เป็นไปไม่ได้ที่จะเพิ่มส่วนหัวส่วนขยายใหม่ให้กับ IPv6 stackoverflow.com/questions/9847923/…
— AdamIerymenko

10
และใช่ดูเหมือนว่าความยาวส่วนหัวของการคำนวณต้องใช้การข้ามรายการที่เชื่อมโยง: stackoverflow.com/questions/14762193/… อย่าเข้าใจฉันผิด IPv6 นั้นยอดเยี่ยมและจำเป็นมาก แต่สิ่งนี้ยังคงดูเหมือนกระดูกหัว
— AdamIerymenko

3
ข้อมูลจำเพาะ (ลิงก์ในความคิดเห็นด้านบน) บอกว่าเราเตอร์ไม่ควรดูที่ส่วนหัวดังนั้นไม่ควรสนใจว่าคุณจะเพิ่มส่วนหัวใด เฉพาะโหนดปลายทางเท่านั้นที่ควรมองไปที่ส่วนหัว
— Anders E. Andersen

2
เพียงบันทึก: "ผมสติ" คือการสะกดคำที่ค่อนข้างสับสนและ "ขาดสติ" ควรจะแนะนำ (ที่มา: TFD )
— PzKpfw

2
Insofar เนื่องจากมีการสะกดที่ถูกต้องเพียงคำเดียวซึ่งก็คือ 'hare-brained'
— Alan B

คำตอบ:


33

หากคุณพบบางสิ่งที่คุณไม่สามารถแยกวิเคราะห์ได้คุณต้องตัดสินใจหรือดำเนินการตามสิ่งที่คุณได้แยกวิเคราะห์ไปแล้ว

การออกแบบเป็นเช่นนั้นเนื่องจากใน IPv6 ส่วนหัวของส่วนขยายแต่ละส่วนจะ "ห่อ" ส่วนที่เหลือของแพ็กเก็ต หากคุณเห็นส่วนหัวของการกำหนดเส้นทางแสดงว่าส่วนหัวบางส่วนที่คุณไม่เคยได้ยินมาก่อนจากนั้นก็แสดงว่าเพย์โหลดคุณจะไม่สามารถแยกวิเคราะห์ส่วนหัวของข้อมูลได้ ความหมายของน้ำหนักบรรทุกขึ้นอยู่กับส่วนหัวที่คุณไม่รู้ว่าจะตีความอย่างไร

เราเตอร์สามารถกำหนดเส้นทางแพ็กเก็ตดังกล่าวได้เนื่องจากสิ่งที่ต้องการคือส่วนหัวของการกำหนดเส้นทาง แกดเจ็ตการตรวจสอบแพ็คเก็ตแบบลึกและสิ่งนั้นจำเป็นต้องรู้มาก แต่นั่นก็เป็นชะตากรรมของพวกเขา

แก้ไขเพื่อเพิ่ม: การออกแบบนี้หมายความว่ากล่องกลางสามารถเปลี่ยนแปลงสิ่งที่พวกเขารู้ได้เท่านั้น หากกล่องกลางเห็นส่วนหัวที่ไม่รู้แสดงว่ามีเพียงสองตัวเลือกเท่านั้น: ปฏิเสธหรือส่งต่อ ใน IPv4 ยังสามารถลบส่วนขยายที่ไม่รู้จักและส่งต่อส่วนที่เหลือได้ IMO คุณสมบัตินี้ทำให้การออกแบบมากกว่าที่จะขยายได้น้อยลง


97

จะเกิดอะไรขึ้นหากฉันพบประเภทส่วนหัวของส่วนขยายที่ไม่รู้จัก

จากRFC 2460 :

หากเป็นผลมาจากการประมวลผลส่วนหัวโหนดจำเป็นต้องดำเนินการต่อไปยังส่วนหัวถัดไป แต่ค่าของส่วนหัวถัดไปในส่วนหัวปัจจุบันไม่รู้จักโดยโหนดควรทิ้งแพ็กเก็ตและส่งข้อความ ICMP Parameter Problem ไปยังต้นทาง ของแพ็กเก็ตโดยมีค่า ICMP Code เป็น 1 ("ไม่รู้จักประเภทส่วนหัวถัดไปที่พบ") ​​และฟิลด์ ICMP Pointer ที่มีค่าชดเชยของค่าที่ไม่รู้จักภายในแพ็กเก็ตดั้งเดิม ควรดำเนินการแบบเดียวกันนี้หากโหนดพบค่า Next Header เป็นศูนย์ในส่วนหัวใด ๆ นอกเหนือจากส่วนหัว IPv6


15
ดี. ฉันคิดว่าฉันกำลังเสียสติ ใช่แล้วมันเป็นการออกแบบที่ไม่สามารถขยายได้อย่างสมบูรณ์ ... อย่างน้อยก็ไม่มีสัญญาณในวงและแฮ็กอื่น ๆ นั่นเป็นข้อแก้ตัวในโปรโตคอลแอปพลิเคชันที่คุณควบคุมปลายทั้งสองข้างและต้องคำนึงถึงแอปเวอร์ชันใหม่เท่านั้น แต่ไม่ได้อยู่ในสิ่งที่ออกแบบมาให้ใช้งานได้นาน ... หลายร้อยปี?
— AdamIerymenko

8
การมีความสามารถในการละเว้นส่วนหัวที่ไม่รู้จักจะนำไปสู่ปัญหาที่ซับซ้อนมากขึ้น (จะเกิดอะไรขึ้นถ้าพร็อกซีระดับกลางแก้ไขส่วนหัว TCP โดยไม่มีความรู้เกี่ยวกับส่วนหัว ESP ที่ห่อหุ้ม) ความเรียบง่ายจะเต้น "ขยายได้" ในกรณีนี้!
— jman

4
@Max IPv6 มีที่อยู่มากพอที่จะกำหนดหนึ่งให้กับทุกๆอะตอมบนโลกได้ ไม่มีเครื่องปิ้งขนมปังที่เชื่อมต่ออินเทอร์เน็ตจำนวนมากที่จะทำให้พื้นที่นี้หมดลง
— Tyler McHenry

8
@ Max ฉันจะไม่บอกว่าเราไม่ต้องการ IPv7 อย่างแน่นอน แต่ด้วย IPv6 เรามีพื้นที่แอดเดรสเพียงพอที่จะให้แต่ละลูกบาศก์มิลลิเมตรในชั้นบรรยากาศโลก (130,000 กิโลเมตรขึ้นไป) ที่อยู่ที่ไม่ซ้ำกัน ... มากกว่า 100,000 ครั้ง ฉันหมายความว่าเมื่อเราเริ่มตั้งรกรากกาแลคซีอื่น ๆ เราอาจมีบางอย่างที่ต้องกังวล แต่ถึงตอนนั้นเราก็น่าจะดี
— cincodenada

4
ขาดบริบทบางส่วน:With one exception, extension headers are not examined or processed by any node along a packet's delivery path, until the packet reaches the node (or each of the set of nodes, in the case of multicast) identified in the Destination Address field of the IPv6 header.
— Tobu

28

เป็นไปไม่ได้ (ในโลกแห่งความเป็นจริง) ที่จะเพิ่มส่วนหัวส่วนขยายใหม่ให้กับ IPv6

ไม่ถูกต้องเนื่องจาก:

  1. เฉพาะโฮสต์ปลายทางเท่านั้นที่ได้รับอนุญาตให้ปฏิเสธตามส่วนหัวของส่วนขยายที่ไม่รู้จัก (โดยมีข้อยกเว้นที่กล่าวถึงในคำถามที่คุณเชื่อมโยง )

  2. หากส่วนหัวส่วนขยายใหม่ของคุณเป็นทางเลือก (ควรจะดีกว่า) คุณจะได้รับข้อผิดพลาด ICMP เกี่ยวกับเรื่องนั้นและสามารถลองอีกครั้งได้โดยไม่ต้องใช้


1
และคุณมั่นใจว่าแพ็กเก็ต ICMP นั้นจะส่งผ่าน NAT ไปยังผู้ส่งจริงหรือไม่?
— Dexter

5
@Dexter ipv6 จะฆ่า NAT ... หวังว่า
— Janus Troelsen

2
@Dexter: แพ็คเก็ต ICMP เหล่านั้นต้องมาถึงด้วยเหตุผลหลายประการ ตัวอย่างเช่นหาก MTU ของไปป์หดตัวลง (บางทีการห่อหุ้มแพ็กเก็ตอาจเกิดขึ้นเนื่องจาก PPPoE หรือ VPN) และแพ็กเก็ตที่ส่งมีขนาดใหญ่เกินไปแพ็กเก็ต ICMP จะถูกส่งกลับโดยแจ้งว่าแพ็กเก็ตมีขนาดใหญ่เกินไป
— Bill Lynch

4
@JanusTroelsen ไม่ใช่ทุกคนที่แบ่งปันความหวังของคุณ
— Dexter

4

การอัปเดตRFC 6564ครอบคลุมกรณีนี้ มันจัดวางสถานการณ์ที่คุณอธิบายไว้อย่างถูกต้องและวางรูปแบบสำหรับส่วนหัวส่วนขยายใหม่ (หากมีการกำหนดไว้) ซึ่งกล่องกลางเช่นของคุณจะสามารถใช้งานได้อย่างน้อยก็ในบางครั้ง

โปรดทราบว่าไม่ได้มีวัตถุประสงค์เพื่อขยาย IPv6 โดยการสร้างส่วนหัวส่วนขยายใหม่ แต่เพิ่มตัวเลือกปลายทางใหม่ ควรเป็นเรื่องเล็กน้อยหรืออย่างน้อยก็ง่ายกว่ามากสำหรับคุณในการจัดการกับตัวเลือกปลายทางที่ไม่รู้จัก

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.