الخلاصة

  • لم تكن القيم user وheader وsession وid وhistory درجات متصاعدة، بل طلبات تخص مساحات مختلفة من رسالة SIP.
  • صُنّفت Identity/Identity-Info وPath وReplaces وRoute وService-Route وTarget-Dialog كعناصر غير مستهدفة مباشرة، مع إمكان معالجة بعضها لسبب آخر مستقل مثل بطلان دليل سلامة أو إصلاح ترابط Call-ID.
  • يجب أن يفصل السجل بين الطلب، وتصنيف الهدف، والقاعدة المستقلة، والتغيير المنفذ، والحالة المحتفظ بها، واستمرار وظيفة البروتوكول، وما انكشف فعلاً لكل مراقب.

حين أصبح الإخفاء سبباً في عدم الوصول

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

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

نُشرت RFC 5379 في فبراير 2010 كوثيقة Informational ضمن Independent Stream. قالت بوضوح إنها تشرح التشغيل العملي لآلية الخصوصية في RFC 3323 وامتدادات RFC 3325 وRFC 4244، ولا تغيّر الآلية ولا تضيف سلوكاً معيارياً جديداً.

لهذا كانت وظيفتها ضبط الحدود. لم تمنح الوسيط أمراً أوسع؛ بل شرحت ماذا تعني الأوامر الموجودة وأين تتوقف.

قيم متجاورة لا سلّم واحد

تتناول user معلومات أدخلها المستخدم، وتتناول header معلومات إشارة أضافتها الشبكة، وتتناول session بيانات وصف الجلسة. أما id فيرتبط بـP-Asserted-Identity في نموذج الثقة الوارد في RFC 3325، وhistory يرتبط بـHistory-Info. وتؤدي none وcritical وظيفتين مختلفتين أيضاً.

ليست هذه قائمة من الأقل إلى الأكثر خصوصية. لا تشمل session كل ما يتعلق بالمكالمة، ولا تتيح user تعديل كل معرّف يُرى في الرسالة.

رتبت RFC 5379 الحقول في مصفوفة. اختلف الفعل بين الحذف، وعدم الإضافة، وإخفاء الهوية، والمعالجة المشروطة، وعدم الفعل. كما اختلف الحكم بين الطلب والاستجابة. وفي SDP حُددت الأسطر c وm وo وi وu وe وp عند Privacy:session.

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

القائمة غير المستهدفة لم تكن قائمة معلومات آمنة

ذكرت الوثيقة Identity/Identity-Info وPath وReplaces وRoute وService-Route وTarget-Dialog كعناصر لا تستهدفها القيم المذكورة. لا ينبغي تعديلها لمجرد وجود قيمة في Privacy.

هذا لا يعني أنها خالية من معلومات حساسة. قد يكشف Route أسماء الوكلاء، وقد يشير Identity-Info إلى شهادة الموقّع، وقد تربط Replaces وTarget-Dialog حواراً بحوار آخر. الفرق أن الحساسية تصف خطراً، ولا تعيّن الجهة المخوّلة بالفعل.

يُجبر Route الطلب على المرور عبر وكلاء معينين. تغيير قيمته طلباً لمظهر مجهول قد يمنع التوجيه. ويساعد Path على إعادة الوصول إلى المستخدم المسجل في مجال زائر. ويصف Service-Route طريق الخدمة الذي يقدمه المسجل. أما Replaces فيحدد الحوار الذي سيحل حوار جديد محله.

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

قد يتغير غير المستهدف بسبب مستقل

لا يجوز تحويل عبارة «غير مستهدف» إلى حظر مطلق. يوضح مثال Identity السبب.

في الآلية التاريخية لـRFC 4474، كانت Identity تحمي بالتوقيع From وTo وCall-ID وCSeq وDate وContact ومتن الرسالة. إذا عدلت خدمة الخصوصية واحداً من هذه العناصر بصورة مشروعة، لم يعد التوقيع يثبت الرسالة الجديدة.

لم تصبح Identity هدفاً لقيمة Privacy. ومع ذلك، قد يلزم حذفها لأنها أصبحت دليلاً باطلاً. مصدر الفعل الثاني هو قاعدة السلامة: تغيرت المدخلات المحمية. وهو مصدر مختلف عن طلب المستخدم الذي أجاز التغيير الأول.

يجب أن يظهر ذلك في سجلين مترابطين: عُدل الحقل المستهدف وفق الطلب؛ ثم أزيل دليل السلامة لأن التعديل أبطله. كتابة «حذفت Privacy هوية التوقيع» توسع الطلب بأثر رجعي.

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

معرّف الحوار أنشأ التزاماً يتجاوز الرسالة

عندما تغيّر الخدمة Call-ID من C1 إلى C2، فإنها تنشئ اسمين للحوار نفسه. قد يظهر الاسم لاحقاً في In-Reply-To أو Replaces أو معامل replaces أو Target-Dialog.

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

تبيّن أمثلة النقل في RFC 5379 كيف يفشل REFER. يعرف طرف الحوار باسم، ويحمل INVITE الجديد الاسم الآخر. إذا لم تمر الرسالة بالخدمة التي تملك الخريطة، أو انتهت مدة الخريطة، فلن يجد المستقبل الحوار المطلوب استبداله. يمكن أن تكون كل رسالة صحيحة نحوياً، بينما تكون العملية الكاملة مكسورة.

لذلك يجب تحديد مدة الحالة، وتكرارها بين العقد الاحتياطية، واستعادتها بعد إعادة التشغيل، وضمان مرور الرسائل المعنية بالخدمة. ومن يغيّر Call-ID يملك هذه المسؤولية حتى تنتهي كل المراجع الممكنة.

السياسة المحلية لا تتكلم بصوت المستخدم

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

إخفاء الطوبولوجيا، وإزالة P-Asserted-Identity عند حدود غير موثوقة، وحذف توقيع باطل، واستعادة Route بعد تغيير Record-Route، أعمال لها جهات وأسباب مختلفة.

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

القاعدة أوسع من SIP: السجل دليل على طبقة محدودة من الواقع، وليس أمراً يخلق طبقات أخرى. Privacy يسجل طلباً، والمصفوفة تسجل تفسيره، وسجل الخدمة يسجل الفعل، ومسار المكالمة يسجل التنفيذ، واختبار المراقب يسجل النتيجة.

لا خصوصية من دون تحديد المراقب

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

لذلك يجب أن تقول النتيجة: أي معلومة حُجبت، عن أي جهة، خلال أي رسائل وتدفقات، ولأي مدة؟ من بقي قادراً على الربط؟ ومتى تُمحى الحالة؟

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

اختفاء الحقل لا يثبت عمل المكالمة. ونجاح المكالمة لا يثبت اختفاء المعلومة. تساعد مصفوفة RFC 5379 على التنفيذ المتسق، لكنها لا تصدر حكماً شاملاً على كل نشر.

الحالة الوثائقية سجل مستقل

كون RFC 5379 وثيقة Informational من Independent Stream جزء من معناها. نسبت لغتها المعيارية إلى الوثائق الموجودة ولم تدع إضافة سلوك جديد. يجب ربط كل التزام بمصدره الفعلي.

كما تغيرت بعض المراجع: حلت RFC 7044 محل RFC 4244، وحلت RFC 8224 محل RFC 4474. تظل الأمثلة التاريخية مفيدة لفهم الحد، لكن متطلبات النشر الحالي تُراجع في الخلفاء.

ويسجل سجل IANA لمعاملات SIP الأسماء والمراجع المشتركة. لا يثبت أن المنتج يدعم القيمة أو يحافظ على الحالة أو يحقق الخصوصية.

يجب أن يحتفظ ملف الإثبات بما يلي:

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

تفصل هذه السلسلة بين وجود الطلب وسلطة التعديل، وبين التعديل والنجاح، وبين نجاح الاتصال ونجاح الخصوصية.