الخلاصة

  • تقترح draft-ietf-opsawg-ipfix-quic-header-00 سبعة عناصر معلومات IPFIX لملاحظات رؤوس QUIC ومعرّفات الاتصال وأرقام الحزم وأنواع الإطارات ومعرّفات التدفقات، وتتطلب الحقول الثلاثة المحمية فك التشفير.
  • لا يثبت الحقل المملوء إلا ما استعاده مصدّر محدد وفق إعداد بعينه؛ ولا يثبت اكتمال هوية الاتصال أو مشروعية استخدام المفاتيح أو الاستمرار بعد تغيير المسار أو معالجة التطبيق.

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

المحفوظ في الحقيقة هو ما استطاع موضع واحد ملاحظته.

تقترح مسودّة مجموعة OPSAWG المنشورة في 10 سبتمبر العناصر quicHeaderFlag وquicVersion وquicDestinationConnectionID وquicSourceConnectionID وquicPacketNumber وquicFrameType وquicStreamID. تتضمن الأعلام والإصدار ومعرّفات الاتصال في الرؤوس الطويلة مواد ظاهرة على السلك. أما رقم الحزمة ونوع الإطار ومعرّف التدفق فمحمية، ولا تظهر إلا عند طرف أو جهاز على المسار ينجح في فك QUIC.

حتى المادة الظاهرة تحتاج إلى افتراض خارجي. لا يحمل الرأس القصير طول Destination Connection ID. ولذلك يحتاج المحلل الوسيط إلى معرفة المعرّف أو طوله مسبقاً. إذا كان الإعداد قديماً أو يخص حركة أخرى، قد يبدو الحقل صحيح البنية بينما قُطّعت البايتات على نحو خاطئ. يجب أن ترافق فرضية التحليل القيمة ضمن سلسلة المصدر.

وتأتي حدود ثانية من كلمة Flow. توضح المسودّة أنها تستخدم تعريف IPFIX لا مفهوماً خاصاً باتصال QUIC. يعرّف RFC 7011 التدفق بأنه حزم أو إطارات تمر بموضع ملاحظة خلال فترة وتشترك في خصائص. ويمكن لعملية القياس أن تختار وتعيّن وتؤرّخ وتشتق قبل إنشاء Flow Record. لذا يصف السجل قياساً مهيأً ولا يمثل تلقائياً تاريخ الاتصال بين الطرفين.

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

ولا تشكل أرقام الحزم سلسلة عالمية. لدى QUIC مساحات منفصلة لـ Initial وHandshake وApplication Data، كما يهم اتجاه المرور. قد تكون الفجوة خسارة حقيقية، لكنها قد تنتج أيضاً من أخذ العينات أو مسار آخر أو بدء الرصد متأخراً أو غياب المفاتيح أو فقد Data Records أثناء التصدير. يسمح RFC 7011 بالاختيار ويشرح حساب سجلات يسقطها المصدّر تحت الضغط. وجود رقمين حول الفجوة لا يثبت اكتمال ما بينهما.

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

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

تقول فقرة الأمن في revision 00 إنه لا توجد اعتبارات إضافية على RFC 7012. لا يعني ذلك غياب المخاطر التي يعالجها RFC 7011: توثيق المصدّر والجامع، سلامة الرسائل، سرية المرور، الخصوصية، والرسائل أو Templates المزيفة. تحيط هذه الضوابط بعنصر المعلومات؛ ولا يمكن استنتاجها من قيمته.

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

لا تلغي هذه الحدود فائدة المقترح. تقلل عناصر المعلومات المشتركة المخططات الخاصة وتنقل ملاحظات محددة بين الأدوات. لكن النص الحالي ما زال Internet-Draft في revision 00، وحالته في Datatracker هي I-D Exists. ليس RFC ولا دليلاً على الانتشار أو النتيجة التشغيلية.

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

المصادر