طلبت الرزمة المسار الأكثر أماناً. لم تعد الشبكة بالسرية: RFC 1455

الخلاصة

• خصصت RFC 1455 قيمة TOS رقم 15 لطلب المسار ذي «أقصى أمن فيزيائي للوصلة»، أي أفضل طريق متاح لتقليل الرصد الخفي من خارج الشبكة، لا لتقرير مستوى أمني مضمون.
• كانت كل شبكة تترجم الطلب بواسطة كلف نسبية محلية للوصلات ومواقع الموجّهات. لذلك أثبتت العلامة نية المرسل فقط، ولم تثبت سياسة مشتركة أو مساراً فعلياً أو تشفيراً أو سرية.
• تكمن قيمة المقترح اليوم في حدوده الإثباتية: لا يجوز أن يتحول وصف خدمة في رأس الرزمة إلى ادعاء عن النتيجة من دون سجلات تربط التفسير بالقرار والتنفيذ والحالة الفيزيائية والمشاهدة.

أربع بتات، وسياق كامل خارج الرزمة

نشرت RFC 1455 في مايو/أيار 1993 بوصفها وثيقة تجريبية. اختارت الرقم 15 عشرياً، أو F ست عشرياً، أو 1111 ثنائياً في حقل نوع الخدمة IPv4. كان هذا النمط على أبعد مسافة هامنج ممكنة من قيم TOS الأخرى المعرّفة آنذاك، بهدف تقليل الالتباس بين الرموز.

لم تكن كثرة الواحدات مقياساً لقوة الحماية. فقد أوضحت RFC 1349 أن قيم TOS أعداد معدودة مستقلة، وليست أعلاماً يمكن جمعها بعملية OR. لم تعن 1111 جمع تقليل التأخير وتعظيم الإنتاجية والموثوقية وخفض الكلفة؛ بل عنت طلباً واحداً جديداً محدداً بالقيمة كلها.

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

ما الذي كان المقترح يحاول حمايته؟

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

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

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

كلمة «أقصى» كانت ترتيباً لا حداً أدنى

طلبت القيمة الجديدة أن تقلل الشبكة فرصة الرصد السري قدر استطاعتها. أكدت RFC 1455 أن ذلك لا يضمن مستوى محدداً من الأمن. «الأقصى» كان يعني الأفضل بين الخيارات التي تراها الشبكة وفق سياستها، لا عتبة مطلقة يحق للمرسل افتراضها.

لو لم يوجد إلا طريقان ضعيفان، فقد يكون أحدهما هو الأكثر أماناً نسبياً مع بقائه غير مناسب لمهمة حساسة. ولو لم تفهم عقدة ما الطلب، لم تتحول إلى عقدة آمنة بمجرد مرور القيمة 15 في رأس الرزمة. الضمان كان يتطلب حجز موارد أو توجيهاً قائماً على سياسة وآليات تتجاوز حقل TOS المتاح.

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

الشبكة هي التي صنعت المقياس

اقترحت RFC 1455 استخدام توجيه مدرك لـ TOS، بما في ذلك الإمكانات الموجودة حينها في OSPF. يعيّن المشغّل كلفة خاصة بهذا الهدف لكل وصلة ولموقع الموجّه أيضاً. وذكرت الوثيقة صراحة أن تحديد الكلف وظيفة سياسة محلية.

قدمت مثالاً يبدأ بكلفة 1 لتشفير قوي للوصلة مع توزيع آمن للمفاتيح. أعطت وصلة نقطة إلى نقطة محمية فيزيائياً كلفة 2، ووصلات نقطة إلى نقطة عادية 6، ووسطاً محلياً متعدد النقاط 8، ووسطاً حضرياً متعدد النقاط 12، وراديو محلياً 24، ووصلة قمر صناعي 32.

لم تكن هذه نتائج قياس. الرقم 32 لا يعني احتمال اعتراض قدره 32 في المئة، ولا يثبت أن القمر الصناعي أسوأ دائماً بمقدار ثابت. كانت النسب مثالاً على معتقد تشغيلي: في تلك السياسة الافتراضية، عوملت بعض الوسائط على أنها أكثر تعرضاً من الوصلة المشفرة المرجعية.

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

قد ينتصر خمسون عبوراً على اثنين

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

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

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

معادلة مناسبة للعمل وليست برهان احتمال

تجمع خوارزميات التوجيه كلف الوصلات عادة. لاحظت RFC 1455 أن ضرب احتمالات الإرسال الآمن أنسب لهذا الهدف من الناحية النظرية، لكنها قبلت الجمع كتقريب مناسب لمعظم الاستخدامات، على نحو يشبه معالجة RFC 1349 للموثوقية العالية.

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

يظل التقريب مفيداً إذا سُمّي كما هو: مسار مفضّل وفق هذه السياسة وهذا النموذج. لا يصبح شهادة تشفير أو تعهداً بعدم الاعتراض.

الوصول لا يثبت تنفيذ الطلب

وصفت RFC 1349 نوع الخدمة بأنه «مطلوب». كانت الشبكة تحاول التقليل أو التعظيم بما لديها من معلومات قد تكون ناقصة. وتبنت توجيه TOS الضعيف: إذا لم يوجد مسار يطابق طلباً غير افتراضي، جاز استخدام مسار TOS الافتراضي بدلاً من إسقاط الرزمة.

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

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

التصنيف الأمني كان آلية أخرى

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

لم تحمل قيمة RFC 1455 تصنيفاً أو سلطة حماية. طلبت فقط أقل الطرق الفيزيائية تعرضاً بحسب المتاح. يمكن أن تتكامل الآليتان، لكن لا يجوز استنتاج إحداهما من الأخرى. كما أن أياً منهما لا يشفر المحتوى تلقائياً؛ تبقى المفاتيح وضوابط الطرفين وحقيقة التعرض سجلات منفصلة.

تغيرت لغة الأوكتت

أبطلت RFC 2474 لاحقاً تعريفات TOS القديمة وقدمت حقل الخدمات المتمايزة. صار DSCP يختار سلوكاً في كل قفزة، بينما تبني المصنفات ومكيفات المرور والسياسات عند حدود النطاق الخدمة الفعلية.

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

من العلامة إلى السرية المرصودة

يمكن كتابة سلسلة الإثبات هكذا:

تفضيل المرسل ← رمز مفهوم ← سياسة محلية سارية ← مسار محسوب ← توجيه فعلي ← حماية الوصلات والموجّهات ← حالة التشفير ← صلاحية الطرف النهائي ← نتيجة مرصودة

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

لم تحل RFC 1455 مشكلة السرية. إنجازها التاريخي الأدق أنها سمحت للطلب أن يدخل الرزمة، ثم رفضت أن تمنحه سلطة النتيجة.

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

ترد حالة الوثيقة وتاريخها وإبطالها في سجل RFC 1455 لدى RFC Editor. ويرد تعريف الطلب ونموذج التهديد وجدول الكلف ومثال المسار والتقريب في نص RFC 1455. أما قواعد القيمة المعدودة ودلالة الطلب والعودة الضعيفة إلى المسار الافتراضي فترد في RFC 1349. وتصف RFC 1108 آلية التصنيف وسلطات الحماية المنفصلة. ويثبت سجل RFC 2474 لدى RFC Editor الاستبدال اللاحق لدلالات الحقل.

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