الخلاصة

  • عرّف RFC 791 النوع 130 بصيغة ثابتة من أحد عشر ثمانيّة تجمع الأمن والمقصورات وقيود التداول ورمز التحكم في الإرسال؛ ثم أبقت المراجعات اللاحقة رقم النوع وغيّرت البنية الداخلية.
  • جعل RFC 1108 مستوى التصنيف وسلطات الحماية مدخلات لسياسة تُطبّق على كل واجهة، مع إمكان حمل وسم صريح أو الاعتماد على وسم ضمني في شبكة مخصصة.
  • مع أن RFC 1108 صار Historic وأن هذه الرزم لا يُفترض أن تظهر عادة على الإنترنت العام، حذّر RFC 7126 المعدات العامة من حذفها أو إسقاطها افتراضياً لأن ذلك قد ينسب البيانات إلى حساسية خاطئة داخل شبكة MLS مغلقة.

غياب الوسم ليس قيمة محايدة

تكمن المفارقة في ما يشرحه RFC 7126. إذا نزع وسيط Basic Security Option فقد يرفض الطرف الآخر الرزمة لأن السياسة تشترط وجود الخيار. لكن واجهة أخرى قد تقبل الرزمة غير الموسومة وتضع بدلاً منه تصنيفها الضمني المحلي.

يمكن أن يسير الخطأ في الاتجاهين. رفع الحساسية بغير حق يحجب استخداماً مشروعاً وقد يُدخل بيانات إلى نظام أعلى تصنيفاً. وخفضها بغير حق يعرّض المعلومات لنطاق لا ينبغي أن يراها. لم يزل جدار الحماية آلية تشفير أو إثبات هوية؛ لقد استبدل مدخلاً صريحاً بقاعدة لا يعرفها لدى المستقبل.

الخيار لا يشفّر الحمولة ولا يوثّق المرسل ولا يثبت تصريحاً أمنياً. إنه وسم تقرؤه مكونات موثوقة، وتأتي قوته من التعيين المحمي والإعداد الصحيح وحراسة الحدود، لا من وجود عدة بِتّات في الرزمة.

حمل التصميم الأول أربعة أبعاد في أحد عشر ثمانيّة

عرّف RFC 791 Security بوصفه خياراً من النوع 130 بطول ثابت يبلغ أحد عشر ثمانيّة. وبعد النوع والطول جاء حقل Security من 16 بت، ثم Compartments من 16 بت، وHandling Restrictions من 16 بت، وTransmission Control Code من 24 بت.

اختار Security مستوى مسمى، وفصل Compartments فئات خاضعة للرقابة، ومثّل Handling Restrictions علامات التداول والإفراج، وحدد TCC جماعات اهتمام مضبوطة. لم تكن الترويسة تقول «سري أو غير سري» فقط؛ بل حاولت نقل عدة محاور من نظام خارجي للتحكم في المعلومات.

كان بِتّ النسخ مفعلاً، فيظهر الخيار في كل جزء بعد التجزئة، ولا يجوز وروده أكثر من مرة في الداتاغرام. لم يكن تقسيم IPv4 ينبغي أن يفصل بعض المحتوى عن سياقه الأمني.

كما فرّق RFC 791 بين اختيار وجود الخيار في رزمة معينة وضرورة أن تنفذه وحدات IP. وقد تتطلب بعض البيئات Security في كل داتاغرام. وهكذا احتوت صيغة عالمية على قدرة لا تصبح إلزامية إلا داخل بيئة بعينها.

لم يمنح أي من هذه الحقول سلامة تشفيرية. نسخ الادعاء إلى كل جزء لا يجعله صحيحاً. كان لا بد من مصادر ووسطاء ومستقبلين موثوقين كي يتحول الوسم إلى قيد فعلي.

بقي الرقم وتبدلت القواعد التي تليه

في 1988 أعاد RFC 1038 بناء النوع 130 بوصفه Basic Security Option متغير الطول. اختفت المقصورات وقيود التداول وTCC ذات المواضع الثابتة، وحل محلها مستوى تصنيف وأعلام لسلطات الحماية.

لذلك لا يكفي رقم 130 لتفسير التقاط شبكي. فالطول والمواصفة الحاكمة يحددان معنى الثمانيّات التالية. يستطيع معرّف واحد في السجل أن يستمر فيما تُستبدل صيغته بطريقة غير متوافقة.

عرض RFC 1038 الوسم كأداة تمكّن المكونات الموثوقة من التحقق من حق المصدر في الإرسال، ومن كفاية حماية المسار والوجهة، ومن توفير تمثيل مشترك لنماذج تحكم مختلفة. لكن ذلك افترض بنية معتمدة وتوجيهاً مدركاً للأمن؛ لم يخلق وجود الخيار الثقة من تلقاء نفسه.

ثم أبطل RFC 1108 سريان RFC 1038 ووصف Basic وExtended Security Options. ظل Basic يحمل النوع 130، لكن الحد الأدنى لطوله أصبح ثلاث ثمانيّات حين يغيب حقل Protection Authority. حتى أصغر جسم تغيّر تحت الرقم نفسه.

لم تكن رموز التصنيف أرقاماً قابلة للترتيب

خصص RFC 1108 ثمانيّة واحدة لـ Classification Level، وكانت القيم الصحيحة أنماطاً متناثرة تعني Top Secret أو Secret أو Confidential أو Unclassified، فيما بقيت أنماط أخرى محجوزة. لم يطابق ترتيبها العددي ترتيب حساسيتها.

لا يستطيع البرنامج إذاً قبول كل قيمة تقع حسابياً بين Confidential وSecret؛ فذلك يدخل رموزاً غير معيّنة. عليه أن يطابق النمط مع الجدول أولاً، ثم يستعمل الترتيب الذي يعرّفه الجدول.

اختيرت الأنماط بمسافة هامنغ دنيا مقدارها أربعة بين القيم الصحيحة. تقل بذلك فرصة أن يحوّل عدد صغير من أخطاء البتات تصنيفاً صحيحاً مباشرة إلى تصنيف صحيح آخر. هذه خاصية لاكتشاف الخطأ، وليست تشفيراً أو توثيقاً أو دليلاً على المنشأ؛ يستطيع فاعل متعمد كتابة رمز صحيح آخر.

وضع التصميم ترتيب السياسة في مفردات مُدارة خارج الحساب العددي. حجم الثمانيّة لا يخبر عن الحساسية، وعلى التنفيذ أن يعرف التعيينات بدلاً من استنتاج السلطة من القيمة.

أعلام السلطة كانت مراجع لقواعد وليست شهادات

بعد التصنيف سمح RFC 1108 بحقل Protection Authority متغير. كانت البتات السبعة العليا في كل ثمانيّة أعلاماً، ويشير البت الأدنى إلى وجود امتداد. يمكن أن تنطبق عدة سلطات على الداتاغرام، وكان على الحد الأدنى من التنفيذ معالجة ثمانيّتين على الأقل من الأعلام.

حددت الأعلام برامج تنطبق قواعد حمايتها على المعلومات. ونبّهت المواصفة صراحة إلى أنها ليست سلطات اعتماد. لم يمنح العلم تصريحاً لمستخدم، ولم يصادق على مضيف، ولم يثبت أهلية الجهة المرسلة.

وجب أن يكون الترميز في أقصر صورة، بلا ثمانيّة امتداد أخيرة لا تحمل أي علم. كما وجب أن يطابق الطول المشار إليه طول الخيار. لم يكن الامتداد المعيب قائمة شارات مجهولة يمكن تجاهلها، بل خطأ بروتوكولياً.

وكانت إدارة التعيينات خارج الرزمة أيضاً. لا بد من جهة توافق عليها وتنشرها. حملت الترويسة اختيارات من فضاء أسماء مضبوط، لكنها لم تحمل القواعد نفسها ولا برهان تنفيذها.

تحولت كل واجهة إلى حد للتصنيف

وصف RFC 1108 معاملات على مستوى النظام ومعاملات «لكل منفذ». لا يعني المنفذ هنا رقم TCP أو UDP، بل واجهة الشبكة أو نقطة اتصالها. يمكن للإعداد أن يشترط BSO في الإرسال أو الاستقبال أو كليهما أو لا يشترطه.

كان على الأنظمة التي تعالج بيانات مصنفة أن تولّد الوسم عادة. واستثنيت الشبكات المخصصة أو system-high، حيث تستطيع الواجهة منح الحركة كلها وسماً ضمنياً. فإذا سمحت السياسة بدخول رزمة بلا خيار، أعطاها إعداد الواجهة السياق الناقص.

وهذا يفسر خطر النزع. قد يعني غياب الوسم حركة عادية على واجهة، ومستوى محمياً بعينه على أخرى. إزالة القيمة الصريحة لا تنتج صفراً؛ إنها تحول مصدر التصنيف من الرزمة إلى الإعداد المحلي.

عند الدخول كان النظام يتحقق من أن رمز التصنيف معيّن، ثم يقارنه بأقصى مستوى للواجهة ويفحص سلطات الحماية المسموح بها. وعند الخروج وجب وقوع المستوى بين الحدين الأدنى والأقصى، ودخول الأعلام في مجموعة السلطة المسموحة.

تقترح الرزمة الوسم، وتحدد الواجهة المجال المقبول. لذلك لا يكشف الالتقاط المفصول عن إعداد الواجهة القرار الأمني كاملاً.

كان الرد على الخطأ قراراً أمنياً أيضاً

إذا اشترطت الواجهة BSO ووصلت رزمة من دونه، حدد RFC 1108 رسالة ICMP Parameter Problem مع Code 1 لخيار مطلوب مفقود. أما الوسم سيئ البنية فيستعمل الصيغة العادية، وقد تقود بعض حالات الرفض إلى administratively prohibited.

كانت تلك أقل الإجراءات تقييداً مما تسمح به المواصفة. قد تفرض السياسة المحلية التسجيل أو تنبيه مسؤول أمني أو منع الرد بالكامل. وحتى رسالة التشخيص وجب أن تلائم تصنيف واجهة الخروج.

لا يصح تعميم هذا على كل خيار IPv4 مفقود. تكشف الحالة نظام قبول يكون فيه الصمت والخطأ ووسم الرد قرارات أمنية. يثبت رمز ICMP أن الوسم كان التزاماً محلياً، لكنه ليس محور القصة.

صارت الصيغ القديمة مهجورة وبقيت المراجعة في الموجّه

اعتبر RFC 1122 خيارات الأمن في RFC 791 وRFC 1038 مهجورة. وفي تطبيقات DoD وجّه المصنعين إلى الإرشاد المنقح الذي صار RFC 1108. لم يقل النص إن كل البيئات الموسومة توقفت عن الوجود.

حافظ RFC 1812 على هذا الفصل. كرر أن الصيغتين القديمتين مهجورتان، لكنه قال إن على الموجّهات تنفيذ خيار RFC 1108 المنقح. وكان على الموجّهات المعدة لمستويات أمن متعددة دعم التصفية على أوسمة IPSO.

خصص النموذج لكل واجهة حداً أدنى وأقصى للحساسية. وينبغي إسقاط الرزمة الخارجة عن المجال بصمت مع زيادة عداد. لم يكن هذا source routing أو قائمة مسار، بل اختبار قبول محلي على كل حد.

لا يعمل وضع المواصفة كمفتاح واحد. تصبح صيغة قديمة مهجورة، ويبقى خلفها المنقح وظيفة مشروطة، ثم يصير مستنده Historic، فيما يستمر الاحتياج التشغيلي داخل مجال خاص.

Historic لا يعني أن عداد الاستخدام صار صفراً

يقول RFC 7126 إن هذه الخيارات لا ينبغي أن تظهر عادة على الإنترنت العام العالمي. لكنه يسجل أيضاً استخدام Basic وExtended Security Options في شبكات خاصة متعددة المستويات على أنظمة تجارية ومفتوحة. بل رأى أن انتشار MLS، ومن ثم IPSO، ربما ازداد بعد الخروج من Standards Track.

قد تنسحب آلية من التيار العام وتبقى داخل نطاق متخصص. Historic وصف لحالة RFC، وليس قياساً لحركة اليوم ولا إعلاناً بانعدام التنفيذ ولا أمراً بمحو رقم التسجيل.

يمكن بيع الموجّه نفسه للبيئتين. وقبل الإعداد لا يعرف الجهاز إن كان النوع 130 حمولة غريبة على طرف عام أو وسمًا إلزامياً داخل شبكة مغلقة. لذلك ينبغي للوضع الافتراضي أن يحفظ قرار المشغّل الذي يعرف السياق.

الحفظ لا يساوي الثقة

توصية RFC 7126 محددة: الحذف أو الإسقاط يسبب فشلاً حقيقياً حيث يلزم BSO، بينما مجرد تمريره لا ينشئ ضرراً محدداً جديداً حيث لا يُستخدم. لهذا لا ينبغي للمعدات العامة أن تنزع الخيار أو تسقط الرزمة لمجرد وجوده في الإعداد الافتراضي.

يجوز لمدير بيئة معلومة بأنها لا تستخدم IPSO أن يضبط الإسقاط. وينبغي للجهاز عد رزم BSO لكل واجهة وإتاحة التصفية حسب الوجود والقيم. لا يُطلب من الإنترنت العام فهم الأوسمة المصنفة، بل يُطلب ألا يدمّر وسيط معناها قبل أن تتكلم سياسة النشر.

تمرير البتات من دون تفسير لا يمنحها صدقية. تبقى الثقة والتطبيق شأن نقاط تملك سياسة MLS، بينما يمنع الحفظ إتلاف مدخل يحتاجه ذلك المجال.

أبقى TCP الحديث الاستثناء في ملاحظاته

يسجل RFC 9293 هذا الإرث غير المريح. فقد أدخل منطق TCP القديم معلومات أمن IP ومقصوراته في معالجة الاتصال. وبحلول 2022 كان RFC 1108 Historic، لكن RFC 791 لم يُعدّل لإزالة Security Option.

وضع المستند الحديث المسألة ضمن ملاحظات التنفيذ. قد تظل المعلومات مهمة لتطبيقات MLS، ويجوز لغير MLS تجاهلها. هذا الحد الصريح أدق من ادعاء سلوك عالمي يصلح للبيئتين.

كما يذكر أن إعادة ضبط الاتصالات عند اختلاف قيم compartment أو precedence عُرفت كمسار هجوم محتمل. قد يحمي الوسم قرار القبول داخل نموذج ثقة صحيح، ثم يصبح أداة تعطيل إذا استمرت استجابة قديمة بين الطبقات بصورة آلية خارج ذلك النموذج.

ما الذي تثبته ثمانيّات النوع 130؟

يثبت وجود النوع 130 أن الرزمة تحمل بيانات في موضع مخصص تاريخياً. يساعد الطول والشكل على تحديد المواصفة التي يبدو أن المرسل اتبعها. ويثبت رمز صحيح وحقل سلطة حسن البنية الاتساق التركيبي.

لكنه لا يثبت تصريح المرسل ولا صدق الوسم ولا سرية الحمولة ولا حماية المسار ولا قبول الواجهة التالية. تحتاج تلك النتائج إلى دليل على التعيينات الفعلية والمكونات الموثوقة والإعدادات.

وبالمقابل، لا يثبت الغياب أن البيانات Unclassified. قد تضيف واجهة ذات وسم ضمني مستوى غير ظاهر في الالتقاط. وعندما تنفصل الرزمة عن سياق دخولها تضيع نصف دلالتها.

الدرس الباقي ليس أن الأمن يجب أن يسكن كل ترويسة IP، بل أن حذف بيانات التحكم عملية دلالية. حين يدخل حقل في التحكم الإلزامي بالوصول، قد يكون حفظ خيار غير مفهوم أكثر أماناً من صنع غياب مضلل.

المصادر وحدود الأدلة

مجموعة الأدلة المغلقة هي RFC 791 وRFC 1038 وRFC 1108 وRFC 1122 وRFC 1812 وRFC 7126 وRFC 9293. تثبت هذه النصوص الصيغ والمعالجة وتاريخ الحالة والنصيحة المشروطة. وهي لا تكشف انتشاراً مصنفاً، ولا تقيس حركة حالية، ولا تتحقق من منتجات، ولا تثبت صحة وسم مرصود.