الخلاصة
- تجمع RFC 5124 بين تغذية AVPF الراجعة وحماية SAVP في ملف
SAVPF. - يمكن توزيع وصف جلسة عبر SAP أو البريد أو الويب من دون مسار جواب تفاعلي.
- في هذا النمط يتحمل مُنشئ الجلسة مسؤولية إتاحة بدائل مناسبة وحماية توزيع معلمات الأمن.
- لا يعني ظهور SAVPF في الإعلان أن الطرف الآخر اختاره أو أن المفاتيح أُنشئت أو بقيت سرية.
- تبقي طبقة AVPF قواعد توقيت RTCP، ثم تضيف SAVP حقول SRTCP وتحويلاته.
- تضيف الحماية في السياق الموصوف نحو 10 إلى 20 بايت، و14 بايت في الحالة الافتراضية المذكورة.
- يجب أن يقيس
avg_rtcp_sizeالرزمة المحمية، لأن الحجم الأكبر يقلل تواتر التقارير ضمن الميزانية نفسها. - العلاقة التقريبية
N <= B*T/Rتفصل بين عدد الأحداث والحيز الزمني والحجم. - سلامة SRTCP إلزامية، لكن التشفير قد يكون NULL ومفتاح المجموعة لا يثبت دائماً مرسلاً فريداً.
- عرض بدائل آمنة وغير آمنة يفتح باب التخفيض، ولذلك تحتاج إشارة الاختيار نفسها إلى حماية.
- الاتفاق على ملف لا يثبت قبول الرزمة في سياقها ولا وصولها قبل انتهاء فائدتها ولا استعادة الصورة.
- ينبغي حفظ الإعلان والوصول والمفتاح والرزمة والتوقيت والفعل والنتيجة كسلسلة إيصالات مستقلة.
إعلان لا يستطيع أن يقول «نعم»
قد ينشر مُنشئ جلسة وصفاً على صفحة أو يرسله بالبريد أو عبر SAP. يقرأه المتلقي، لكنه لا يعيد جواباً تفاوضياً إلى المصدر بالطريقة التي يوفرها نموذج العرض والجواب. لذلك لا يوجد إيصال مدمج يقول إن الطرف الآخر قبل الملف، أو فهم سمات التغذية الراجعة، أو استطاع استعمال آلية المفاتيح.
تعترف RFC 5124 بهذه الحدود. عندما لا توجد مفاوضة تفاعلية، تقع على المُنشئ مسؤولية توفير أوصاف بديلة بقدر ما يناسب التطبيق، وعدم إعلان ملفات غير آمنة إذا كان الأمن مطلوباً ما لم توجد وسائل أخرى. كما يجب حماية قناة توزيع المعلمات.
تُظهر أوصاف الأمن في RFC 4568 سبب ذلك بوضوح. عندما تحتوي الصيغة على مادة مفتاح inline، تحتاج القناة التي تحمل الوصف إلى السرية حتى لا يقرأها طرف ثالث أو يعبث بها. استعمال SRTCP لاحقاً لا يعيد سرية مفتاح انكشف أثناء الإعلان.
هذه حالة نموذجية لفصل طبقات الواقع. النص يثبت ما كتبه المُنشئ. الوصول المحمي يثبت من استطاع قراءته. التفاوض، إن وجد، يثبت الاختيار. إدارة المفاتيح تثبت سياقاً مشتركاً. وحدها الرزمة الفعلية تختبر ذلك السياق.
ملف مركب لا يمحو حساب الوقت
عرّفت RFC 4585 ملف AVPF لتمكين تقارير RTCP مبكرة، وعرّفت RFC 3711 ملف SAVP لحماية RTP وRTCP. تجمع RFC 5124 الوظيفتين. تظل AVPF تقرر متى تُجدول رزمة التغذية الراجعة، ثم تعالجها طبقة SAVP كرزمة SRTCP.
يجب تغليف كل RTCP في SAVPF وفق SRTCP. تضاف فهارس ووسوم مصادقة وحقول أخرى حسب الإعداد. تذكر الوثيقة أن الزيادة في السياق الذي تناقشه تكون غالباً 10 إلى 20 بايت على الأقل، مع 14 بايت في الحالة الافتراضية. قد تتغير الزيادة مع أطوال الحقول والتحويلات.
هذه البايتات تدخل ميزانية RTCP. لذلك تُلزم RFC 5124 بتعديل avg_rtcp_size كي يعكس حجم SRTCP. إذا بقي متوسط الرزمة المفتوحة، يتصرف المجدول كما لو كان يستطيع إرسال تقارير أكثر مما يسمح به الحيز الفعلي.
تقدم RFC 4585 العلاقة التقريبية N <= B*T/R لوضع Immediate Feedback. عند ثبات عرض النطاق B والمهلة T، يؤدي ازدياد متوسط الحجم R إلى تقليل عدد الأحداث N التي يمكن الإبلاغ عنها. الأمن صحيح، لكن فرصة الإصلاح تتقلص إن لم تُحسب الكلفة.
من الفوري إلى المبكر ثم العادي
في Immediate Feedback توجد سعة تكفي تقريباً لكل حدث مهم. في Early RTCP لا يمكن الإبلاغ عن كل شيء، لكن بعض الرسائل ما زالت تصل في وقت يسمح بتعديل الإرسال. في Regular RTCP يصبح التقرير الفردي غير مفيد بسبب حجم المجموعة أو المقياس الزمني.
لا يحدد عدد ثابت الحدود. يؤثر نوع التقرير، معدل الرزم، الخسارة، برنامج الترميز، تكرار الأحداث والحجم المحمي. قد تنتقل الجلسة باتجاه نمط أبطأ من دون انقطاع الاتصال ومن دون فشل تشفيري.
يسمي معيار AVPF الحد الأقصى المفيد للتأخير T_max_fb_delay. يختلف حسب التطبيق. قد تصل رزمة صحيحة ومصادق عليها بعد موعد عرض الإطار. حينها ينجح إيصال الأمن ويفشل إيصال التوقيت.
ولا يكفي الوصول في الموعد. ربما لا يحتفظ المرسل بالرزمة، أو يختار تكييفاً آخر، أو تضيع إعادة الإرسال، أو يكون مفكك الترميز قد فقد مرجعه. تحتاج النتيجة إلى ربط اكتشاف الحدث والجدولة والإرسال والقبول ورد المرسل ووصول الوسيط وحالة فك الترميز.
كلمة «آمن» ليست خدمة واحدة
يمكن لـ SRTP وSRTCP توفير السرية والسلامة أو مصادقة الرسالة ومنع الإعادة. تجعل RFC 3711 سلامة SRTCP إلزامية لأن العبث برسائل التحكم قد يضر التدفق، لكنها تفصل التشفير وتسمح بتحويل NULL. لذا لا يثبت اسم SAVPF أن محتوى التحكم كان سرياً.
في مجموعة تتشارك مفتاحاً، قد يثبت الوسم الصحيح أن أحد حاملي المفتاح أرسل الرزمة، لا أي عضو بالتحديد. تنبه RFC 3711 إلى أن «المصادقة» في بعض هذه الحالات تكون عملياً سلامة. يجب أن يتبع وصف الهوية نموذج المفاتيح الحقيقي.
السياق يشمل الخوارزمية والمفتاح الرئيسي ومفاتيح الجلسة وفهرس SRTCP ونافذة الإعادة وفترة الصلاحية وMKI عند استعماله. رمز SDP لا يحتوي نتيجة تلك الفحوص. قد تُرفض رزمة سليمة شكلاً لأنها تنتمي إلى حقبة مفتاح قديمة.
حماية الاختيار قبل حماية التقارير
تحذر RFC 5124 من جمع البدائل الآمنة وغير الآمنة في عرض واحد بسبب هجمات bidding down. إذا عُرض النوعان، يجب حماية إشارة التفاوض بطريقة مناسبة. وضع SAVPF أولاً لا يثبت أن القائمة وصلت كما أُرسلت.
تبدأ حماية SRTCP بعد الاختيار وإنشاء المفاتيح. لا تستطيع العودة لتصديق وصف غير محمي حُذف منه البديل الآمن. لهذا يلزم إيصال لسلامة العرض وترتيبه وسماته والجواب، لا مجرد اسم الملف النهائي.
في وصف وسائط واحد تكون AVP وAVPF وSAVP وSAVPF اختيارات متنافية. إذا لم يدعم المجيب SAVPF فعليه رفض ذلك الوسيط. وإذا أراد SAVPF بينما لم يعرضه الطرف الأول، فعليه الرفض ويمكنه تقديم عرض مضاد لاحقاً. لا يجوز تحويل الجواب بصمت إلى ملف آخر.
التفاوض لكل وسيط. قد يعمل الصوت ويفشل الفيديو. كما يمكن استعمال ملفات مختلفة عبر جلسات RTP مختلفة. لذلك لا تملك علامة واحدة على مستوى «المكالمة» دقة كافية.
حدود التوافق وإعادة البناء
يمكن لكيانات SAVP وSAVPF أن تتعايش في جلسة RTP آمنة واحدة، كما يمكن لـ AVP وAVPF في جلسة غير آمنة. لا يجوز خلط العائلتين الآمنة وغير الآمنة في الجلسة نفسها لأن RTP وSRTP غير قابلين للتشغيل البيني بهذه الصورة.
في إجراء RTSP الوارد في RFC 5124 يختار العميل ملفاً واحداً لكل تدفق في SETUP، ويؤكده الخادم أو يرفضه. تغيير الملف يحتاج، في ذلك الإجراء، إلى TEARDOWN ثم SETUP جديد. هذا انتقال حالة يتطلب دليلاً على إنهاء السياق القديم وبناء النقل والمفتاح الجديدين.
حلت RFC 8866 لاحقاً محل مواصفة SDP القديمة، وحلت RFC 7826 محل RTSP القديم، وقدمت RFC 5763 وRFC 5764 سياق DTLS-SRTP اللاحق. هذه حقائق دورة حياة وليست تحديثاً معلناً لـ RFC 5124 ولا دليلاً على نشر حالي.
يسجل محرر RFC الوثيقة كـ Proposed Standard من فبراير 2008 من دون علاقات تحديث أو إبطال. يثبت سجل IANA تخصيص المعلمات. ولا تعرض المصادر المجمدة منتجاً مسمى أو حادثة أو حصة استخدام أو قياس استعادة، ولذلك لا تدعي المقالة شيئاً من ذلك.
المصادر
- https://www.rfc-editor.org/rfc/rfc5124.html
- https://www.rfc-editor.org/rfc/rfc5124.txt
- https://www.rfc-editor.org/info/rfc5124
- https://www.rfc-editor.org/errata_search.php?rfc=5124
- https://datatracker.ietf.org/doc/rfc5124/
- https://datatracker.ietf.org/doc/rfc5124/history/
- https://www.rfc-editor.org/rfc/rfc3550.html
- https://www.rfc-editor.org/rfc/rfc3551.html
- https://www.rfc-editor.org/rfc/rfc3711.html
- https://www.rfc-editor.org/rfc/rfc4585.html
- https://www.rfc-editor.org/rfc/rfc3264.html
- https://www.rfc-editor.org/rfc/rfc4566.html
- https://www.rfc-editor.org/rfc/rfc4567.html
- https://www.rfc-editor.org/rfc/rfc4568.html
- https://www.rfc-editor.org/rfc/rfc2326.html
- https://www.rfc-editor.org/rfc/rfc2974.html
- https://www.rfc-editor.org/rfc/rfc5763.html
- https://www.rfc-editor.org/rfc/rfc5764.html
- https://www.rfc-editor.org/rfc/rfc7826.html
- https://www.rfc-editor.org/rfc/rfc8866.html
- https://www.iana.org/assignments/rtp-parameters/rtp-parameters.xhtml
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
- https://heng.lu/on-reality-layers-symbolic-power-and-why-clarity-feels-so-hostile/
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
إحاطة الأعضاء
سياق أعمق للملف الشخصي
سجّل الدخول بمستوى العضوية المناسب لفتح الإحاطة الكاملة وملاحظات المصادر.
للدائرة الاستراتيجية فقط
الدائرة الاستراتيجية
مفتوح لجميع القراء. افتح إحاطات الملف الشخصي بعد الانضمام وتسجيل الدخول.
انضم إلى الدائرة الاستراتيجيةلأعضاء تحالف القيادات فقط
تحالف القيادات
لأصحاب الأصول الفكرية المؤهلين وللإدارة؛ سجّل الدخول للوصول إلى إحاطات التحالف.
انضم إلى تحالف القيادات
