الخلاصة

  • يذكر دليل ARIN الحالي أن تصريح ROA قد يحمل اسماً اختيارياً، فيما يوثق البحث في ARIN Online باستخدام البادئة أو ASN فقط.
  • طلب اقتراح ACSP 2024.14 البحث بالاسم؛ عدّت ARIN الفكرة مفيدة في أغسطس 2024 وأدرجتها ضمن تحسينات RPKI المنتظرة للأولوية، وما زال الاقتراح بحالة Open.
  • تحمل واجهة RPKI REST الاسم عند الإنشاء والإدراج، ولذلك يستطيع مستخدم مخوّل جلب قائمة المؤسسة وتصفيتها محلياً.
  • ينبغي أن يبقى الاسم فهرساً خاصاً قابلاً للتغيير، وأن يعتمد تعديل السجل أو حذفه على معرّف ROA ثابت مع مراجعة البادئة وASN.

اسم يدخل إلى السجل ولا يفتح طريق العودة إليه

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

يعترف دليل Route Origin Authorizations لدى ARIN بهذا الدور، إذ يعدّ الاسم عنصراً اختيارياً إلى جانب Origin AS والبادئة. لكن الجزء الذي يشرح العثور على سجلات المؤسسة في ARIN Online يذكر البحث عن بادئة محددة أو ASN، ولا يذكر الاسم كمفتاح. وهكذا يكتمل إدخال الحقل، ولا تكتمل طريقة استرجاعه في العقد العام للواجهة.

وضع اقتراح ACSP 2024.14 إصبعه على هذه الوصلة. قُدّم في 23 أغسطس 2024، وطالب بالبحث في سجلات ROA التابعة للمؤسسة بالاسم، إضافة إلى البادئة أو ASN، حتى يمكن جمع السجلات المرتبطة بعميل أو مشروع.

جاء رد ARIN في 28 أغسطس مؤيداً للفائدة العملية. قالت إن البحث بالاسم سيُحسن خيارات البحث القائمة، وإن الطلب سيدخل قائمة تحسينات RPKI ريثما تحدد أولويته، وسيظل مفتوحاً حتى تطوير الوظيفة ونشرها. والصفحة الخاصة بالاقتراح، مثل فهرس ACSP الحالي المحفوظ لهذه المقالة، ما زالت تعرض الحالة Open.

لا يسمح هذا السجل بتجاوز حدوده. فهو لا يثبت غياب ميزة حديثة أو غير موثقة من كل حساب موثّق؛ لم تُستخدم أي جلسة ARIN Online في هذا التحقيق، ولم يُنشأ أو يُعدّل أو يُحذف أي ROA. كما لا توجد مهلة فائتة لأن ARIN لم تعلن تاريخاً للتسليم. الثابت أضيق: الاسم حقل مقبول في الوثائق، لكنه ليس من مفاتيح البحث الإلكتروني التي تشرحها الوثائق العامة الحالية.

التصفية المحلية عبر API دفاع عملي قوي

تقدم وثائق RPKI REST أقوى اعتراض على ضرورة إضافة البحث إلى الموقع. يحتوي مثال الإنشاء على عنصر name، وتعيد حمولة ROA Spec Payload الاسم أيضاً. أما عملية الإدراج الموثقة فتسترجع سجلات ROA المرتبطة بمعرّف المؤسسة. يستطيع فريق مخوّل إذن تنزيل المجموعة كاملة ثم تصفية الأسماء في أداة داخلية.

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

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

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

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

وسم الإدارة ليس جزءاً من سلطة ROA الموقعة

تختصر كلمة ROA سلسلة من حالات مختلفة: سجل الإدارة لدى ARIN، والكائن الموقع وفق المعيار، ونشره في مستودع RPKI، والصورة التي يراها المدقق، وإعلان BGP المشاهد، ثم سياسة الشبكة التي تقرر قبول المسار أو رفضه.

تتكون بنية RouteOriginAttestation في RFC 6482 من الإصدار ومعرّف AS وكتل عناوين IP، ولا تحتوي اسماً وصفياً. ويقول دليل ARIN إن التحقق من الحالة الفاعلة يتطلب مدقق RPKI ومستودع ARIN. لذلك فإن العثور على سجل اسمه «ترحيل-العميل-الأزرق» لا يثبت نشر الكائن الموقع، ولا وصول المدقق إليه، ولا وجود إعلان مطابق، ولا قبول شبكة له.

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

البحث الآمن يحتاج إلى معرّف ثابت وإيصال صغير

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

يجب أن تعرض كل نتيجة معرّف ROA ثابتاً بجوار الاسم وOrigin AS والبادئة والطول الأقصى والحالة. ولا يُنفذ تعديل أو حذف إلا بعد تأكيد المعرّف والإحداثيات الشبكية. الاسم يدل على قائمة مرشحين؛ ولا ينبغي أن يصبح هوية السجل النهائية.

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

يبقى الإيصال خاصاً ولا يكشف أسماء العملاء. وظيفته أن يتيح إعادة بناء ما عرضه النظام قبل فعل مهم. بهذا المعنى لا يطلب ACSP 2024.14 منح الاسم سلطة أمنية جديدة؛ بل يطلب إكمال دورة حياة حقل تقبله ARIN وتعيده بالفعل.

المصادر