الخلاصة

  • نقل RFC 2351 نوعين مختلفين من حركة الطيران إلى TCP/IP: كان Type A تفاعلياً ويقبل الفقد وإعادة الطلب بعد الصمت، أما Type B فاحتاج حماية عالية وعناوين متعددة وأربع درجات أولوية.
  • يثبت اتصال TCP وجلسة MATIP المقبولة توافق الطرفين على طريقة النقل، ولا يثبتان أن مقعداً حُجز أو تذكرة أُصدرت أو التكرار كان آمناً أو مسؤولية رسالة بعينها انتقلت.

في عام 1998 لم تكن كلفة تغيير الشبكة مساوية لكلفة تغيير العمل الذي يمر فيها. أصبحت حزم TCP/IP أرخص وانتشرت الشبكات الداخلية، لكن آلاف مكاتب شركات الطيران ظلت تعتمد محطات P1024B وP1024C وتطبيقات مركزية بُنيت على بروتوكولات ترجع جذورها إلى الستينيات.

قدّم RFC 2351 بروتوكول MATIP، أي Mapping of Airline Traffic over Internet Protocol. لم يحاول إعادة كتابة أنظمة الحجز وإصدار التذاكر والمراسلة. وضع طبقة مشتركة بين TCP وتطبيق الطيران كي لا تبقى كل مؤسسة أسيرة بوابة خاصة لا تتوافق مع غيرها. وكانت فضيلته الأهم أنه لم يحوّل النقل المشترك إلى ادعاء بأن كل حركة لها النتيجة نفسها.

جعل Type A الصمت سبباً لإعادة المحاولة

شمل Type A الحوار بين مكتب شركة الطيران أو وكالة السفر وبين الحاسوب المركزي للحجز والتذاكر. كان فورياً وعالي الأولوية، لكن حمايته محدودة ويمكن إسقاطه. ويقول RFC إنه إذا لم يصل رد بسبب فقد البيانات، جاز للمستخدم تكرار الطلب.

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

احتفظ MATIP بالسياق اللازم لإيصال الحركة إلى ذلك التطبيق. تفاوضت الجلسة على النوع الفرعي والترميز والعرض والرأس والتجميع. أمكن للحقول H1 وH2 وA1 وA2 تعريف مجموعة محطات بمعزل عن عنوان IP، وأمكن استعمال Flow ID بين المضيفين. هذه محددات مسار داخل البروتوكول، لا إثبات لهوية الشخص أو سلطته على الحجز أو لما ثبّته النظام المركزي.

حمل Type B عبئاً آخر

كان Type B نظام مراسلة لا يحتاج إلى الجواب الفوري نفسه، لكنه تطلب حماية عالية وإرسالاً إلى عناوين متعددة وأربع درجات أولوية. وضع RFC 2351 بروتوكول BATAP فوق MATIP بوصفه بروتوكول تطبيق إلى تطبيق لحماية حركة Type B.

تضمنت Session Open للنوع Type B الحقل PROTEC لتحديد بروتوكول انتقال مسؤولية الرسالة من طرف إلى طرف. وإذا اختلفت آلية الحماية بين الطرفين أمكن لـ Open Confirm رفض الجلسة. وعُرّف المرسل والمتلقي بواسطة HLD أو بزوج عناوين IP.

لكن الاتفاق على الآلية ليس إيصال انتقال المسؤولية. يعني تطابق PROTEC أن الطرفين يفهمان البروتوكول نفسه. ولا يعني أن BATAP قبل رسالة بعينها، أو أن جميع المرسل إليهم استلموها، أو أن الحيازة انتقلت فعلاً. يحتاج ذلك إلى إقرار التطبيق وحالته اللاحقة.

فصلت المنافذ الحركة ولم تغلق المعاملة

خُصص منفذ TCP 350 لـ Type A والمنفذ 351 لـ Type B. احتاج كل طقم من المعاملات اتصال TCP وجلسة MATIP مستقلين. أعلنت Session Open خصائص الحركة، وقبلتها أو رفضتها Open Confirm، وأغلقت Session Close طبقة MATIP. لم يعرّف MATIP آلية keep-alive خاصة به، واعتمد انتهاء المهلة على TCP.

تداخلت دورتا الحياة من دون أن تتطابقا. لا تبقى جلسة MATIP إذا سقط TCP، لكن إغلاق MATIP لا يوجب إغلاق TCP. لذلك لا يثبت اتصال TCP الحي أن جلسة تطبيق الطيران صالحة، ولا تثبت جلسة MATIP المقبولة أن العمل اكتمل.

قدّم RFC 793 في TCP تدفق بايتات موثوقاً ومرتباً بين العمليات، وحدد RFC 1122 ما يجب على المضيف تنفيذه في طبقات الاتصال. لا ترى أي من الطبقتين مخزون المقاعد أو رقم التذكرة أو قبول متلقي Type B للمسؤولية.

سلسلة الإثبات أطول: مسار الشبكة، إنشاء TCP، Session Open، Open Confirm، ASCU أو Flow ID أو HLD المسموح، وصول البيانات، إقرار التطبيق، انتقال المسؤولية، تثبيت حالة العمل، ثم مصالحة التكرار أو الفشل الجزئي. اختصار هذه المراحل يمنح النقل معرفة لا يملكها.

كشف تحذير الأمان حدود جسر التوافق

سمح RFC 2351 بتعريف ASCU من إعداد ثابت أو اسم مستخدم وكلمة مرور، وبالتحكم عبر جدار ناري على مستوى IP أو التطبيق. وجعل IPsec ESP وAH اختياريين. ويضيف RFC Editor اليوم تحذيراً أمنياً: المعرّفات الثابتة وكلمات المرور الظاهرة كنص صريح ليست حماية سليمة، فيما بقي IPsec القوي اختيارياً.

لا يلغي ذلك فائدة MATIP، بل يحدد نطاقها. حل الجسر مشكلة الانتقال والتوافق، ولم يستطع تحويل تسمية قديمة إلى تفويض مشفر. وصف RFC 4301 لاحقاً سياسات IPsec وSecurity Associations، لكن وجود القدرة لا يثبت أن تبادلاً بعينه استعمل الحماية المتوقعة؛ يلزم سجل تشغيل.

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

المصادر