การแยกวิเคราะห์ส่วนหัวของส่วนขยาย 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.