الخلاصة
- يشترط GAAP-25 أن يجمع تشفير الـClaim بين السرية والسلامة، ويحظر استخدام ChaCha20 منفرداً، لكن الـMarker يدل على أن السجل مشفّر ولا يدل على هوية المرسل أو حقه في العنوان.
- قد تنقسم العقد ذات المفتاح والعقد التي لا تملكه إلى مجالين لا يرى أحدهما مطالبات الآخر؛ وحتى داخل المجال المشفّر لا يثبت نجاح المصادقة سوى امتلاك مادة مفتاحية مقبولة.
قد يعني غياب الـClaim أن العنوان شاغر. وقد يعني أيضاً أن المطالبة موجودة، لكنها مكتوبة بمفتاح لا يستطيع المستقبِل قراءته. الفرق بين الحالتين هو جوهر حدود GAAP-25: التشفير يمنع بعض الأطراف من رؤية الرسالة، لكنه لا يمنح الأطراف التي تراها صورة كاملة عن الاستخدام الفعلي.
تصف المراجعة 25 من مسودة GAAP آلية خفيفة ولامركزية لتنسيق عناوين البث المتعدد داخل نطاق إداري. يُشتق عنوان مرشح من تجزئة Group Name. وإذا استخدم اسمان مختلفان العنوان نفسه وقع تعارض، ويمكن للطالب الانتقال إلى ثلاثة مواضع بديلة حتمية بإضافة 1 أو 2 أو 3 إلى الاسم. ترسل العقدة Claim أولياً، وتنتظر نحو فترة دورية واحدة، ثم تحافظ على الحالة المؤقتة برسائل دورية. أما التحرير فيحدث محلياً بالتوقف عن الإرسال.
لا يجوز تقديم ذلك كمنتج منشور أو نتيجة تشغيلية مثبتة. يسجل IETF Datatracker الوثيقة كمسودة يُقصد لها أن تكون Experimental وفي مرحلة IESG Evaluation::AD Followup. ويعرض سجل المراجعات تطور النص لا انتشار البروتوكول. بل تقول المسودة إن النهج اللامركزي القائم على التجزئة لم يُنشر، وإن معدلات التعارض وسلوكه عند التوسع لم تُقاس.
ما الذي أصلحته المراجعة 25
أصبحت القاعدة أوضح مما كانت عليه في المراجعة 23. فإذا شُفّر الـClaim وجب استخدام آلية توفر السرية والسلامة معاً، مثل AEAD. ويحظر النص استخدام ChaCha20 وحده. يوضح RFC 8439 سبب ذلك: تشفير الدفق من دون مصادقة قابل للتطويع؛ فيستطيع المهاجم تعديل النص المشفّر بحيث يتغير بعد الفك عنوان المجموعة أو الطابع الزمني أو الاسم بصورة متوقعة.
وتشترط المسودة أيضاً عدم تكرار الـnonce مع المفتاح نفسه بين جميع المرسلين الذين يتشاركونه، كما تلزم المستقبِل المهيأ بمفتاح برفض Claim غير مشفّر. يمنع ذلك هبوط النطاق المحمي بصمت إلى النمط المفتوح.
غير أن الـMarker ليس شهادة هوية. إنه إشارة ضمنية إلى أن السجل مشفّر، ولا يحمل خوارزمية عالمية أو سلسلة شهادات أو تفويضاً. تبقى الآلية والمفاتيح وبنية السجل والبيانات المرتبطة وتصميم الـnonce وتبديل المفاتيح إلى حد كبير خارج البروتوكول. وعندما يفشل فك التشفير يُهمَل السجل. لذلك قد تنتهي المفاتيح المختلفة، والآليات غير المتوافقة، والتلف العرضي، والتلاعب المتعمد إلى النتيجة المرئية نفسها: لا Claim.
سلامة الرسالة ليست شرعية التخصيص
ترفض العقدة ذات المفتاح الرسائل الواضحة، ولا تفهم العقدة من دون مفتاح الرسائل المشفرة. وهكذا يمكن لمجموعتين على الشبكة المادية نفسها أن تستخدما العنوان نفسه، بينما تعتقد كل منهما أنه غير متنازع عليه. يحمي التشفير ما تراه المجموعة، لكنه لا يضمن أنها ترى جميع الأطراف المعنية.
حتى بين حاملي المفتاح يبقى النقص قائماً. فالمشارك الخبيث الذي يمتلك السر يستطيع إنشاء Claim ينجح تماماً في المصادقة. قد تنتج مقارنة الطوابع الزمنية وقاعدة الحسم فائزاً بروتوكولياً، لكن ذلك لا يثبت حسن النية. ولهذا صُممت Bad Actor List كقائمة محلية محدودة وإرشادية؛ يمكن انتحال عنوان المصدر، والخسارة في مقارنة زمنية ليست دليلاً على السلوك الخبيث.
يوفر RFC 1982 حساب أرقام التسلسل، ويقدم RFC 8085 إرشادات تشغيل UDP. وتضع RFC 2365 وRFC 5771 وRFC 2730 وRFC 2909 سياق النطاقات والآليات السابقة. أما RFC 10019 وRFC 10028 فيصفان البنية الحديثة والفجوة التي تدفع إلى البحث عن خيار أبسط. لا تجعل أي منها صحة الحزمة دليلاً على ملكية المورد.
الخلاصة العملية ثلاثية: يثبت التشفير سلامة الرسالة داخل نظام مفاتيح محدد؛ ويقارن GAAP المطالبات المرئية؛ وتقرر سلطة خارجية من كان مخولاً بإرسال المطالبة.
البساطة لا تلغي القوة
تنسجم أطروحة Lu Heng عن الحد الأدنى للمواصفة الأولية والقرار المحلي اللاحق والتبني الطوعي مع الطبيعة التجريبية لـGAAP. من المعقول تجربة آلية محدودة قبل بناء مؤسسة واسعة حولها.
لكن الوظائف المستبعدة من الحزمة لا تختفي. من يوزع المفتاح يقبل الأعضاء، ومن يسحبه يستبعدهم، ومن يحدد دائرة فك التشفير يحدد التعارضات التي تصبح حقيقة مشتركة. قد يتحول مدير المفاتيح، من دون قرار صريح، إلى بوابة تخصيص فعلية.
ويتطلب مبدأ أولوية الكود العامل اختبار الواقع: ما الذي يراه المستقبِلون فعلاً؟ ماذا يحدث عند فشل التدوير؟ من يكتشف مجموعتين متداخلتين؟ ومن يتحمل انقطاع الخدمة؟ كلمة «مشفّر» لا تجيب.
تناول مقال BTW السابق عن GAAP-23 ونطاقات العناوين والتقارب بعد الانقسام مسألة أخرى: قد يبقى Group Name واحد على عنوانين احتياطيين مختلفين بعد عودة الاتصال. لا تزعم المراجعة 25 حل ذلك. لكنها تكشف أن المفاتيح نفسها تستطيع صنع انقسام منطقي من دون انقطاع مادي.
قدمت المراجعة 25 ظرفاً أمنياً أقوى. أما حق وضع المطالبة داخله فلا بد أن يثبت خارج ذلك الظرف.
المصادر
- مسودة GAAP، المراجعة 25
- سجل IETF Datatracker
- تاريخ وثيقة IETF
- مسودة GAAP، المراجعة 23
- تحليل BTW السابق لـGAAP-23
- RFC 10019: بنية تخصيص عناوين البث المتعدد
- RFC 10028: تحليل فجوة تخصيص البث المتعدد
- RFC 8439: ChaCha20 وPoly1305
- RFC 1982: حساب أرقام التسلسل
- RFC 8085: إرشادات استخدام UDP
- RFC 2365: البث المتعدد ذي النطاق الإداري
- RFC 5771: تخصيصات عناوين IPv4 متعددة البث
- RFC 2730: بروتوكول MADCAP
- RFC 2909: خيار تداخل نطاق MADCAP
- الحد الأدنى للمواصفة والقرار المحلي والتبني الطوعي
- أولوية الكود العامل
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات

