بروتوكول أمان الإنترنت (IPsec)

الموسوعة الحرة

في مجال الحوسبة ، يُعدّ بروتوكول أمان الإنترنت ( IPsec ) مجموعة بروتوكولات شبكية آمنة تُستخدم للتحقق من هوية حزم البيانات وتشفيرها لتوفير اتصال مشفر آمن بين جهازين عبر شبكة بروتوكول الإنترنت . ويُستخدم هذا البروتوكول في الشبكات الخاصة الافتراضية (VPN).

يتضمن بروتوكول IPsec بروتوكولات لإنشاء مصادقة متبادلة بين الأجهزة في بداية الجلسة، والتفاوض على مفاتيح التشفير المستخدمة خلالها. يُمكن لبروتوكول IPsec حماية تدفق البيانات بين جهازين ( مضيف-إلى-مضيف )، أو بين بوابتي أمان ( شبكة-إلى-شبكة )، أو بين بوابة أمان وجهاز ( شبكة-إلى-مضيف ). [ 1 ] يستخدم بروتوكول IPsec خدمات أمان التشفير لحماية الاتصالات عبر شبكات بروتوكول الإنترنت (IP). وهو يدعم مصادقة النظراء على مستوى الشبكة، ومصادقة مصدر البيانات ، وسلامة البيانات ، وسرية البيانات ( التشفير )، والحماية من هجمات إعادة الإرسال .

تاريخ

ابتداءً من أوائل سبعينيات القرن العشرين، رعت وكالة مشاريع الأبحاث المتقدمة سلسلة من أجهزة التشفير التجريبية لشبكة أربانت ، في البداية لتشفير حزم بيانات أربانت الأصلية ، ثم لتشفير حزم بيانات بروتوكول الإنترنت (TCP/IP) ؛ وقد تم اعتماد بعض هذه الأجهزة ونشرها. وفي الفترة من عام ١٩٨٦ إلى عام ١٩٩١، رعت وكالة الأمن القومي الأمريكية (NSA) تطوير بروتوكولات أمان الإنترنت ضمن برنامجها لأنظمة شبكات البيانات الآمنة (SDNS). [ ٢ ] وقد جمع هذا البرنامج العديد من الموردين، بما في ذلك شركة موتورولا التي أنتجت جهاز تشفير للشبكة عام ١٩٨٨. ونُشر هذا العمل علنًا منذ حوالي عام ١٩٨٨ من قِبل المعهد الوطني للمعايير والتكنولوجيا (NIST) ، ومن بين هذه البروتوكولات، تطور بروتوكول الأمان في الطبقة الثالثة (SP3) ليصبح فيما بعد بروتوكول أمان طبقة الشبكة (NLSP) المعياري لمنظمة المعايير الدولية (ISO). [ ٣ ]

في عام ١٩٩٢، موّلت وكالة مشاريع الأبحاث الدفاعية المتقدمة (DARPA) التابعة لمنظمة العلوم والتكنولوجيا الصينية (CSTO) مختبر الأبحاث البحرية الأمريكي (NRL) لتطبيق بروتوكول IPv6، ولإجراء أبحاث وتطبيقات تشفير بروتوكول الإنترنت في نظام التشغيل 4.4 BSD ، الذي يدعم معماريتي المعالجات SPARC وx86. وقد أتاحت DARPA تطبيقها مجانًا عبر معهد ماساتشوستس للتكنولوجيا (MIT). وفي إطار جهود البحث الممولة من DARPA، طوّر مختبر NRL مواصفات مسار معايير IETF (RFC 1825 إلى RFC 1827) لبروتوكول IPsec. [ ٤ ] ووُصف تطبيق IPsec الخاص بـ NRL في ورقتهم البحثية المنشورة في وقائع مؤتمر USENIX لعام ١٩٩٦. [ ٥ ] وقد أتاح معهد MIT تطبيق IPsec مفتوح المصدر الخاص بـ NRL عبر الإنترنت ، وأصبح أساسًا لمعظم التطبيقات التجارية الأولية. [ ٤ ]

شكّلت فرقة عمل هندسة الإنترنت (IETF) فريق عمل أمن بروتوكول الإنترنت (IP Security Working Group) في عام 1992 [ 6 ] لتوحيد معايير امتدادات الأمان المحددة علنًا لبروتوكول الإنترنت، والتي تُسمى IPsec . [ 7 ] وقد نشرت فرقة عمل هندسة الإنترنت (IETF) المعايير التي طورتها مختبرات الأبحاث الوطنية (NRL) تحت مسميات RFC 1825 إلى RFC 1827. [ 8 ]

بنية أمنية

طُوِّرت حزمة بروتوكولات IPv4 الأولية مع القليل من إجراءات الأمان. وكجزء من تحسينات IPv4، يُعدّ بروتوكول IPsec نظام أمان شامل من الطبقة الثالثة في نموذج OSI أو طبقة الإنترنت . في المقابل، بينما تعمل بعض أنظمة أمان الإنترنت الأخرى الشائعة الاستخدام فوق طبقة الشبكة ، مثل بروتوكول أمان طبقة النقل (TLS) الذي يعمل فوق طبقة النقل ، وبروتوكول SSH الذي يعمل على طبقة التطبيقات ، يستطيع IPsec تأمين التطبيقات تلقائيًا على مستوى طبقة الإنترنت .

IPsec هو معيار مفتوح كجزء من مجموعة IPv4 ويستخدم البروتوكولات التالية لأداء وظائف مختلفة: [ 9 ] [ 10 ]

رأس المصادقة

استخدام تنسيق رأس مصادقة IPsec في وضعي النفق والنقل

طُوِّر رأس مصادقة الأمان (AH) في مختبر الأبحاث البحرية الأمريكي في أوائل التسعينيات، وهو مُشتق جزئيًا من معايير IETF السابقة لمصادقة بروتوكول إدارة الشبكة البسيط (SNMP) الإصدار 2. يُعد رأس المصادقة (AH) جزءًا من مجموعة بروتوكولات IPsec. يضمن AH سلامة البيانات دون اتصال باستخدام دالة تجزئة ومفتاح سري مشترك في خوارزمية AH. كما يضمن AH مصدر البيانات من خلال مصادقة حزم IP . يُمكن، اختياريًا، استخدام رقم تسلسلي لحماية محتويات حزمة IPsec من هجمات إعادة الإرسال ، [ 17 ] [ 18 ] باستخدام تقنية النافذة المنزلقة وحذف الحزم القديمة.

  • في بروتوكول IPv4 ، يمنع بروتوكول AH هجمات إدخال الخيارات. أما في بروتوكول IPv6 ، فيوفر بروتوكول AH الحماية ضد هجمات إدخال الرؤوس وهجمات إدخال الخيارات على حد سواء.
  • في بروتوكول IPv4 ، يحمي رأس الحزمة (AH) حمولة IP وجميع حقول رأس حزمة بيانات IP باستثناء الحقول القابلة للتغيير (أي تلك التي قد تتغير أثناء النقل)، بالإضافة إلى خيارات IP مثل خيار أمان IP. [ 19 ] حقول رأس IPv4 القابلة للتغيير (وبالتالي غير المصادق عليها) هي DSCP / ToS و ECN وFlags و Fragment Offset و TTL و Header Checksum . [ 11 ]
  • في بروتوكول IPv6 ، يحمي رأس الحزمة (AH) معظم رأس الحزمة الأساسي، ورأس الحزمة نفسه، ورؤوس الامتداد غير القابلة للتغيير التي تلي رأس الحزمة، وحمولة بروتوكول الإنترنت. ويستثني هذا الحماية الحقول القابلة للتغيير: DSCP و ECN وFlow Label وHop Limit. [ 11 ]

يعمل AH مباشرة فوق IP، باستخدام بروتوكول IP رقم 51. [ 20 ]

يوضح مخطط حزمة AH التالي كيفية إنشاء حزمة AH وتفسيرها: [ 11 ]

تنسيق رأس المصادقة
إزاحةثمانية0123
ثمانيةقليل012345678910111213141516171819202122232425262728293031
00العنوان التاليطول الحمولةمحجوز
432مؤشر معايير الأمان
864رقم التسلسل
1296قيمة فحص السلامة
⋮⋮
العنوان التالي : 8 بت
نوع الترويسة التالية، مما يشير إلى بروتوكول الطبقة العليا الذي تمت حمايته. تُؤخذ القيمة من قائمة أرقام بروتوكولات IP .
طول الحمولة : 8 بت
يُقاس طول رأس المصادقة هذا بوحدات 4 بايت، مطروحًا منه 2. على سبيل المثال، قيمة AH تساوي 4 تساوي 3 × (حقول AH ذات الطول الثابت 32 بت) + 3 × (حقول ICV ذات الطول الثابت 32 بت) - 2، وبالتالي فإن قيمة AH تساوي 4 تعني 24 بايت. مع أن الحجم يُقاس بوحدات 4 بايت، إلا أن طول هذا الرأس يجب أن يكون من مضاعفات 8 بايت إذا تم نقله في حزمة IPv6. لا ينطبق هذا القيد على رأس المصادقة المنقول في حزمة IPv4.
محجوز : 16 بت
محجوز للاستخدام المستقبلي (جميعها أصفار حتى ذلك الحين).
مؤشر معلمات الأمان : 32 بت
قيمة عشوائية يتم استخدامها (مع عنوان IP الوجهة) لتحديد ارتباط الأمان الخاص بالطرف المتلقي.
رقم التسلسل : 32 بت
يُستخدم رقم تسلسلي متزايد بشكل رتيب (يزداد بمقدار 1 مع كل حزمة مُرسلة) لمنع هجمات إعادة الإرسال . عند تفعيل خاصية كشف إعادة الإرسال، لا يُعاد استخدام الأرقام التسلسلية مطلقًا، لأنه يجب إعادة التفاوض على ارتباط أمني جديد قبل محاولة زيادة الرقم التسلسلي إلى ما بعد قيمته القصوى. [ 11 ]
قيمة التحقق من السلامة : مضاعفات العدد 32 بت
قيمة فحص الطول المتغير. قد تحتوي على حشو لمحاذاة الحقل إلى حد 8 بايت لبروتوكول IPv6 ، أو حد 4 بايت لبروتوكول IPv4 .

تغليف حمولة الأمان

استخدام حمولة الأمان المغلفة لبروتوكول IPsec (ESP) في وضعي النفق والنقل

طُوِّر بروتوكول أمان تغليف بروتوكول الإنترنت (ESP) [ 21 ] في مختبر الأبحاث البحرية بدءًا من عام 1992 كجزء من مشروع بحثي برعاية وكالة مشاريع الأبحاث الدفاعية المتقدمة (DARPA) ، ونُشر علنًا من قِبل فريق عمل بروتوكول أمان تغليف بروتوكول الإنترنت ( SIPP ) التابع لفرقة عمل هندسة الإنترنت (IETF) [ 22 ]، والذي صاغه في ديسمبر 1993 كامتداد أمني لبروتوكول SIPP. وقد استُمدّ بروتوكول ESP في الأصل من بروتوكول SP3D التابع لوزارة الدفاع الأمريكية ، وليس من بروتوكول أمان طبقة الشبكة (NLSP) التابع لمنظمة المعايير الدولية (ISO). نُشرت مواصفات بروتوكول SP3D من قِبل المعهد الوطني للمعايير والتكنولوجيا (NIST) في أواخر ثمانينيات القرن الماضي، ولكن صُمِّمت من قِبل مشروع نظام شبكة البيانات الآمنة التابع لوزارة الدفاع الأمريكية . يُعد بروتوكول أمان تغليف بروتوكول الإنترنت (ESP) أحد بروتوكولات أمان بروتوكول الإنترنت (IPsec). ويوفر هذا البروتوكول مصداقية المصدر من خلال مصادقة المصدر ، وسلامة البيانات من خلال دوال التجزئة، وسرية البيانات من خلال حماية التشفير لحزم بروتوكول الإنترنت . يدعم بروتوكول ESP أيضًا تكوينات التشفير فقط والمصادقة فقط، ولكن يُنصح بشدة بعدم استخدام التشفير دون مصادقة لأنه غير آمن. [ 23 ] [ 24 ] [ 25 ]

على عكس رأس المصادقة (AH) ، لا يوفر بروتوكول ESP في وضع النقل سلامة ومصادقة حزمة IP بأكملها . مع ذلك، في وضع النفق ، حيث تُغلّف حزمة IP الأصلية بالكامل مع إضافة رأس حزمة جديد، تُوفّر حماية ESP لحزمة IP الداخلية بأكملها (بما في ذلك الرأس الداخلي)، بينما يبقى الرأس الخارجي (بما في ذلك أي خيارات IPv4 خارجية أو رؤوس امتداد IPv6) غير محمي.

يعمل ESP مباشرة فوق IP، باستخدام بروتوكول IP رقم 50. [ 20 ]

يوضح مخطط حزمة ESP التالي كيفية إنشاء حزمة ESP وتفسيرها: [ 26 ]

تنسيق حمولة الأمان المغلفة
إزاحةثمانية0123
ثمانيةقليل012345678910111213141516171819202122232425262728293031
00مؤشر معايير الأمان
432رقم التسلسل
864بيانات الحمولة
⋮⋮
⋮⋮  
⋮⋮(حشوة)
⋮⋮ طول الوسادةالعنوان التالي
⋮⋮قيمة التحقق من السلامة ⋮
⋮⋮
مؤشر معلمات الأمان  (SPI) : 32 بت
قيمة عشوائية تستخدم (مع عنوان IP الوجهة) لتحديد ارتباط الأمان الخاص بالطرف المتلقي.
رقم التسلسل : 32 بت
يُستخدم رقم تسلسلي متزايد بشكل مطرد (يزداد بمقدار 1 مع كل حزمة بيانات مُرسلة) للحماية من هجمات إعادة الإرسال . ويُحتفظ بعداد منفصل لكل ارتباط أمني.
بيانات الحمولة : متغيرة
المحتويات المحمية لحزمة بروتوكول الإنترنت الأصلية، بما في ذلك أي بيانات استُخدمت لحماية المحتويات (مثل متجه التهيئة لخوارزمية التشفير). ويُشار إلى نوع المحتوى الذي تمت حمايته بواسطة حقل "الرأس التالي" .
الحشو : 0-255 بايت
اختياري. حشو للتشفير، لتوسيع بيانات الحمولة إلى حجم يناسب حجم كتلة التشفير ، ولمحاذاة الحقل التالي.
طول الوسادة : 8 بت
حجم الحشو (بالثمانيات).
العنوان التالي : 8 بت
يشير هذا إلى نوع بروتوكول بيانات الحمولة ، [ 26 ] : §2.6 ، مثل القيمة 6 لبروتوكول TCP . وبما أن ESP بروتوكول تغليف، فمن الممكن أيضًا استخدام القيمة 4 ، مما يشير إلى IP داخل IP . وتشير القيمة 41 إلى IPv6 مُغلّف في IPv4 ، مثل 6to4 . أما القيمة 59 (بمعنى: لا يوجد رأس تالٍ ) فتُستخدم للحزم الوهمية التي قد تُضاف إلى التدفق، والتي يجب تجاهل محتوياتها.
قيمة التحقق من السلامة  (ICV) : متغير
قيمة فحص الطول المتغير. قد تحتوي على حشو لمحاذاة الحقل إلى حد 8 بايت لبروتوكول IPv6 ، أو حد 4 بايت لبروتوكول IPv4 .

جمعية الأمن

تستخدم بروتوكولات IPsec رابطة أمان ، حيث تُحدد الأطراف المتصلة سمات أمان مشتركة مثل الخوارزميات والمفاتيح. وبذلك، يوفر IPsec مجموعة من الخيارات بمجرد تحديد ما إذا كان سيتم استخدام AH أو ESP. قبل تبادل البيانات، يتفق المضيفان على خوارزمية التشفير المتناظر المستخدمة لتشفير حزمة IP، مثل AES أو ChaCha20 ، وعلى دالة التجزئة المستخدمة لضمان سلامة البيانات، مثل BLAKE2 أو SHA256 . يتم الاتفاق على هذه المعايير لجلسة محددة، والتي يجب الاتفاق على مدة صلاحيتها ومفتاح الجلسة الخاص بها . [ 27 ]

يتم الاتفاق على خوارزمية المصادقة قبل نقل البيانات، ويدعم بروتوكول IPsec مجموعة من الطرق. تُمكن المصادقة باستخدام مفتاح مشترك مسبقًا ، حيث يمتلك كلا المضيفين مفتاحًا متماثلًا ، ويتبادلان تجزئات هذا المفتاح المشترك لإثبات امتلاكهما له. كما يدعم IPsec تشفير المفتاح العام ، حيث يمتلك كل مضيف مفتاحًا عامًا ومفتاحًا خاصًا، ويتبادلان مفاتيحهما العامة، ويرسل كل مضيف للآخر قيمة عشوائية مشفرة باستخدام مفتاحه العام. بدلاً من ذلك، إذا كان كلا المضيفين يمتلكان شهادة مفتاح عام من جهة إصدار الشهادات ، فيمكن استخدامها لمصادقة IPsec. [ 28 ]

تُنشأ روابط الأمان في بروتوكول IPsec باستخدام بروتوكول إدارة روابط ومفاتيح أمان الإنترنت (ISAKMP). يُنفذ ISAKMP من خلال التكوين اليدوي باستخدام أسرار مشتركة مسبقًا، وتبادل مفاتيح الإنترنت (IKE وIKEv2)، والتفاوض على مفاتيح الإنترنت المُؤمَّن (KINK)، واستخدام سجلات نظام أسماء النطاقات (DNS) الخاصة بـ IPSECKEY . [ 16 ] [ 1 ] : §1 [ 29 ] يُعرّف RFC 5386 أمانًا أفضل من لا شيء (BTNS) على أنه نمط غير مُصادق عليه لبروتوكول IPsec باستخدام بروتوكول IKE مُوسَّع. وقد استخدم كلٌّ من سي. ميدوز وسي. كريمرز وآخرون أساليب رسمية لتحديد العديد من حالات الشذوذ الموجودة في IKEv1 وكذلك في IKEv2. [ 30 ]

لتحديد مستوى الحماية المطلوب لحزمة بيانات صادرة، يستخدم بروتوكول IPsec مؤشر معلمات الأمان (SPI)، وهو فهرس لقاعدة بيانات ارتباطات الأمان (SADB)، بالإضافة إلى عنوان الوجهة في رأس الحزمة، مما يُحدد بشكل فريد ارتباط الأمان لتلك الحزمة. ويتم اتباع إجراء مماثل لحزمة بيانات واردة، حيث يجمع بروتوكول IPsec مفاتيح فك التشفير والتحقق من قاعدة بيانات ارتباطات الأمان.

في تقنية البث المتعدد عبر بروتوكول الإنترنت، يتم توفير ارتباط أمني للمجموعة، ويُنسخ هذا الارتباط إلى جميع المستلمين المُصرَّح لهم. قد يكون هناك أكثر من ارتباط أمني واحد للمجموعة، باستخدام معرّفات أمان مختلفة، مما يسمح بمستويات ومجموعات أمان متعددة داخل المجموعة. في الواقع، يمكن لكل مُرسِل أن يمتلك ارتباطات أمنية متعددة، مما يُتيح المصادقة، حيث لا يمكن للمستلم التأكد من أن البيانات أُرسلت إلا من قِبل شخص يمتلك المفاتيح. تجدر الإشارة إلى أن المعيار ذي الصلة لا يُحدد كيفية اختيار الارتباط ونسخه عبر المجموعة؛ إذ يُفترض أن جهة مسؤولة هي من قامت بهذا الاختيار.

أجهزة مراقبة الحياة

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

يُعدّ اكتشاف النظير المعطل (DPD) أسلوبًا لاكتشاف نظير معطل في بروتوكول تبادل مفاتيح الإنترنت (IKE). يعتمد هذا الأسلوب على أنماط حركة مرور بروتوكول أمان الإنترنت (IPsec) لتقليل عدد الرسائل المطلوبة لتأكيد توافر النظير. يُستخدم DPD لاستعادة الموارد المفقودة في حال اكتشاف نظير معطل، كما يُستخدم أيضًا لتنفيذ عملية تجاوز الفشل في بروتوكول IKE.

يُعد بروتوكول UDP keepalive بديلاً لبروتوكول DPD.

أنماط التشغيل

يمكن تنفيذ بروتوكولات IPsec AH و ESP في وضع النقل من مضيف إلى مضيف، وكذلك في وضع نفق الشبكة.

أوضاع بروتوكول أمان الإنترنت (IPsec)

نمط النقل

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

تم تحديد وسيلة لتغليف رسائل IPsec لاجتياز NAT (NAT-T) من خلال وثائق RFC التي تصف آلية NAT-T.

وضع النفق

في وضع النفق، يتم تشفير حزمة بروتوكول الإنترنت بالكامل والتحقق من صحتها. ثم يتم تغليفها في حزمة بروتوكول إنترنت جديدة برأس بروتوكول إنترنت جديد. يُستخدم وضع النفق لإنشاء شبكات خاصة افتراضية للاتصالات بين الشبكات (مثل بين أجهزة التوجيه لربط المواقع)، والاتصالات بين الأجهزة والشبكات (مثل وصول المستخدم عن بُعد)، والاتصالات بين الأجهزة (مثل المحادثات الخاصة). [ 31 ]

يدعم وضع النفق اجتياز NAT.

الخوارزميات

خوارزميات التشفير المتناظر

تتضمن خوارزميات التشفير المحددة للاستخدام مع بروتوكول IPsec ما يلي:

راجع RFC 8221 للحصول على التفاصيل.

خوارزميات تبادل المفاتيح

خوارزميات المصادقة

  • RSA
  • ECDSA (RFC 4754)
  • PSK (RFC 6617)
  • EdDSA (RFC 8420)
  • ML-DSA و SLH-DSA (draft-ietf-ipsecme-ikev2-pqc-auth)

التطبيقات

يمكن تطبيق بروتوكول IPsec ضمن حزمة بروتوكولات الإنترنت (IP) لنظام التشغيل . تُستخدم هذه الطريقة في الأجهزة المضيفة وبوابات الأمان. تتوفر حزم بروتوكولات IP متنوعة تدعم IPsec من شركات مثل HP وIBM. [ 32 ] يُعدّ تطبيق "التثبيت في الحزمة " (BITS) بديلاً آخر، حيث لا يتطلب تعديل شفرة المصدر لنظام التشغيل. في هذه الحالة، يُثبّت IPsec بين حزمة بروتوكولات الإنترنت وبرامج تشغيل الشبكة . بهذه الطريقة، يمكن تحديث أنظمة التشغيل لتتوافق مع IPsec. تُستخدم هذه الطريقة أيضًا للأجهزة المضيفة والبوابات. مع ذلك، عند تحديث IPsec، قد يُسبب تغليف حزم IP مشاكل في اكتشاف وحدة الإرسال القصوى (MTU) للمسار تلقائيًا ، حيث يتم تحديد حجم وحدة الإرسال القصوى (MTU) على مسار الشبكة بين جهازين مضيفين. إذا كان لدى الجهاز المضيف أو البوابة معالج تشفير منفصل ، وهو أمر شائع في الأنظمة العسكرية ويمكن إيجاده أيضًا في الأنظمة التجارية، فمن الممكن تطبيق IPsec باستخدام " التثبيت في السلك" (BITW). [ 33 ]

عند تطبيق بروتوكول IPsec في نواة النظام ، تتم إدارة المفاتيح والتفاوض على بروتوكولي ISAKMP و IKE من مساحة المستخدم. غالبًا ما تُستخدم واجهة برمجة تطبيقات إدارة المفاتيح PF_KEY، الإصدار 2، التي طورتها NRL والمُحددة علنًا، لتمكين تطبيق إدارة المفاتيح في مساحة التطبيق من تحديث ارتباطات أمان IPsec المخزنة ضمن تطبيق IPsec في مساحة النواة. [ 34 ] تتضمن تطبيقات IPsec الحالية عادةً بروتوكولات ESP وAH وIKE الإصدار 2. كما تتضمن تطبيقات IPsec الحالية على أنظمة التشغيل الشبيهة بنظام Unix ، مثل Solaris أو Linux ، عادةً واجهة PF_KEY الإصدار 2.

يمكن استخدام بروتوكول IPsec المدمج لضمان الاتصال الآمن بين التطبيقات التي تعمل على أنظمة ذات موارد محدودة مع تكلفة إضافية بسيطة. [ 35 ]

حالة المعايير

طُوِّر بروتوكول IPsec بالتزامن مع بروتوكول IPv6، وكان في الأصل إلزاميًا لجميع تطبيقات IPv6 المتوافقة مع المعايير ، قبل أن يُصبح مجرد توصية بموجب RFC 6434. [ 36 ] كما يُعدّ IPsec اختياريًا لتطبيقات IPv4 . ويُستخدم IPsec غالبًا لتأمين حركة مرور IPv4.

تم تعريف بروتوكولات IPsec في الأصل في الوثائق RFC 1825 إلى RFC 1829، التي نُشرت عام 1995. وفي عام 1998، تم استبدال هذه الوثائق بالوثيقتين RFC 2401 وRFC 2412 مع بعض الاختلافات الهندسية الطفيفة، على الرغم من تطابقهما من حيث المفهوم. بالإضافة إلى ذلك، تم تعريف بروتوكول تبادل المفاتيح والمصادقة المتبادلة، المعروف باسم تبادل مفاتيح الإنترنت (IKE)، لإنشاء وإدارة روابط الأمان. وفي ديسمبر 2005، تم تعريف معايير جديدة في الوثيقتين RFC 4301 وRFC 4309، وهما في الغالب مجموعة شاملة للإصدارات السابقة مع إصدار ثانٍ من معيار تبادل مفاتيح الإنترنت IKEv2 . وقد قامت هذه الوثائق من الجيل الثالث بتوحيد اختصار IPsec إلى "IP" كبير و"sec" صغير. ويشير مصطلح "ESP" عمومًا إلى الوثيقة RFC 4303، وهي أحدث إصدار من المواصفات.

منذ منتصف عام 2008، ينشط فريق عمل صيانة وتوسيع بروتوكول IPsec (ipsecme) في IETF. [ 37 ] [ 38 ]

مزاعم بتدخل وكالة الأمن القومي

في عام 2013، وكجزء من تسريبات سنودن ، كُشف أن وكالة الأمن القومي الأمريكية كانت تعمل بنشاط على "إدخال ثغرات أمنية في أنظمة التشفير التجارية، وأنظمة تكنولوجيا المعلومات، والشبكات، وأجهزة الاتصالات الطرفية المستخدمة من قبل الأهداف" كجزء من برنامج بولرن . [ 39 ] وهناك مزاعم بأن نظام IPsec كان نظام تشفير مستهدفًا. [ 40 ]

ظهرت حزمة بروتوكولات IPsec الخاصة بنظام OpenBSD لاحقًا، وتم نسخها على نطاق واسع. في رسالة تلقاها ثيو دي رادت، كبير مطوري OpenBSD، بتاريخ 11 ديسمبر 2010 من غريغوري بيري، زُعم أن جيسون رايت وآخرين، يعملون لصالح مكتب التحقيقات الفيدرالي، أدخلوا "عددًا من الثغرات الأمنية وآليات تسريب المفاتيح عبر القنوات الجانبية " في شفرة التشفير الخاصة بنظام OpenBSD. في البريد الإلكتروني المُعاد توجيهه من عام 2010، لم يُبدِ ثيو دي رادت في البداية موقفًا رسميًا بشأن صحة هذه الادعاءات، باستثناء تأييده الضمني من خلال إعادة توجيه البريد الإلكتروني. [ 41 ] وكان رد جيسون رايت على هذه الادعاءات: "تزداد كل أسطورة حضرية واقعيةً بإضافة أسماء وتواريخ وأوقات حقيقية. ويندرج بريد غريغوري بيري الإلكتروني ضمن هذه الفئة... أؤكد بوضوح أنني لم أضف أي ثغرات أمنية إلى نظام التشغيل OpenBSD أو إطار عمل التشفير الخاص به (OCF)." [ 42 ] بعد أيام، علّق دي رادت قائلاً: "أعتقد أن شركة NETSEC ربما تعاقدت على كتابة ثغرات أمنية كما يُزعم... وإذا كُتبت هذه الثغرات، فلا أعتقد أنها أُدرجت في نظامنا." [ 43 ] نُشر هذا قبل تسريبات سنودن.

يقدم مؤلفو هجوم Logjam تفسيراً بديلاً مفاده أن وكالة الأمن القومي الأمريكية (NSA) اخترقت شبكات VPN بتقنية IPsec عن طريق تقويض خوارزمية ديفي-هيلمان المستخدمة في تبادل المفاتيح. في ورقتهم البحثية [ 44 ] ، يزعمون أن وكالة الأمن القومي أنشأت خصيصاً مجموعة حاسوبية لحساب المجموعات الفرعية الضربية مسبقاً لأعداد أولية ومولدات محددة، مثل مجموعة أوكلي الثانية المحددة في RFC 2409. اعتباراً من مايو 2015، كان 90% من شبكات VPN بتقنية IPsec القابلة للعنونة تدعم مجموعة أوكلي الثانية كجزء من بروتوكول IKE. إذا قامت أي مؤسسة بحساب هذه المجموعة مسبقاً، فبإمكانها استخلاص المفاتيح المتبادلة وفك تشفير البيانات دون الحاجة إلى إدخال أي ثغرات برمجية.

ثمة تفسير بديل آخر طُرح، وهو أن مجموعة "إيكويشن" استغلت ثغرات أمنية غير معروفة (ثغرات اليوم الصفر) ضد أجهزة VPN تابعة لعدة شركات مصنعة، وقد أكدت مختبرات كاسبرسكي ارتباط هذه الثغرات بمجموعة "إيكويشن" [ 45 ] ، كما أكدت الشركات المصنعة أنها ثغرات حقيقية، بعضها كان ثغرات غير معروفة وقت اكتشافها. [ 46 ] [ 47 ] [ 48 ] كما احتوت جدران الحماية من سيسكو PIX وASA على ثغرات استغلتها وكالة الأمن القومي الأمريكية للتنصت على المكالمات الهاتفية [ 49 ] .

علاوة على ذلك، تُرسل شبكات VPN التي تستخدم بروتوكول IPsec مع إعدادات "الوضع العدواني" تجزئةً لمفتاح المشاركة المسبقة (PSK) بشكلٍ غير مشفر. ويمكن لوكالة الأمن القومي الأمريكية (NSA) استهداف هذا الأمر، ويبدو أنها تستهدفه بالفعل، باستخدام هجمات القاموس غير المتصلة بالإنترنت . [ 44 ] [ 50 ] [ 51 ]

انظر أيضاً

مراجع

  1. 1 2 3 د. هاركنز؛ ر. أتكينسون (نوفمبر 1998). حمولة الأمان المغلفة لبروتوكول الإنترنت (ESP) . مجموعة عمل الشبكة. doi : 10.17487/RFC2406 . RFC 2406 .مُلغى. تم إلغاؤه بموجب RFC 4303 و 4305 . يُلغي RFC 1827 .  
  2. ↑ دال، هيتيش؛ دال، دولي؛ باترا، سونيا؛ راني، بوجا (2012). "تطبيق بروتوكول IPSec". المؤتمر الدولي الثاني لعام 2012 حول تقنيات الحوسبة والاتصالات المتقدمة . IEEE . ص 176-181 . doi : 10.1109/ACCT.2012.64 . ISBN  978-1-4673-0471-9. S2CID 16526652 . 
  3. ↑ جيلمور، جون. "تشفير الشبكة - التاريخ وبراءات الاختراع" . مؤرشف من الأصل بتاريخ 2014-09-03 . تم الاطلاع عليه بتاريخ 2014-02-18 .
  4. 1 2 "صفحة توزيع IPv6 + IPSEC + ISAKMP" . web.mit.edu .
  5. ↑ "المؤتمر التقني السنوي لـ USENIX لعام 1996" . www.usenix.org .
  6. ↑ "بروتوكول أمان بروتوكول الإنترنت (ipsec) -" . datatracker.ietf.org .
  7. ↑ إس. كينت ؛ ك. سيو (ديسمبر 2005). بنية أمان بروتوكول الإنترنت . مجموعة عمل الشبكة. doi : 10.17487/RFC4301 . RFC 4301 .المعيار المقترح. صفحة 4. يلغي RFC 2401. تم تحديثه بواسطة RFC 6040 و 7619 . يُفضّل استخدام التهجئة "IPsec" في هذا المعيار وجميع معايير IPsec ذات الصلة. جميع التهجئات الأخرى لـ IPsec [...] غير مُستحبة.  
  8. ↑ "إنجازات قسم تكنولوجيا المعلومات في مختبرات الأبحاث البحرية الأمريكية - بروتوكول IPSec وبروتوكول IPv6" (ملف PDF) . مختبرات الأبحاث البحرية الأمريكية . مؤرشف من النسخة الأصلية (ملف PDF) بتاريخ 15 سبتمبر 2015.
  9. ↑ إس. فرانكل؛ إس. كريشنان (فبراير 2011). خارطة طريق وثائق أمن بروتوكول الإنترنت (IPsec) وتبادل مفاتيح الإنترنت (IKE) . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6071 . ISSN 2070-1721 . RFC 6071 . معلوماتي. يلغي RFC 2411 . 
  10. ↑ ب. هوفمان (ديسمبر 2005). مجموعات التشفير لبروتوكول أمان الإنترنت (IPsec ). مجموعة عمل الشبكة. doi : 10.17487/RFC4308 . RFC 4308 .المعيار المقترح.
  11. 1 2 3 4 5 إس. كينت (ديسمبر 2005). رأس مصادقة بروتوكول الإنترنت . مجموعة عمل الشبكة. doi : 10.17487/RFC4302 . RFC 4302 .المعيار المقترح. يلغي RFC 2402 . 
  12. ↑ بروتوكول تبادل مفاتيح الإنترنت (IKE)، RFC 2409، القسم 1: الملخص
  13. ↑ إس. كينت ؛ د. كاريل (نوفمبر 1998). بروتوكول تبادل مفاتيح الإنترنت (IKE) . مجموعة عمل الشبكة. doi : 10.17487/RFC2409 . RFC 2409 .مُلغى. تم إلغاؤه بموجب RFC 4306. تم تحديثه بموجب RFC 4109 .  
  14. ↑ سي. كوفمان (ديسمبر 2005). بروتوكول تبادل مفاتيح الإنترنت (IKEv2) . مجموعة عمل الشبكة. doi : 10.17487/RFC4306 . RFC 4306 .مُلغى. أُلغي بموجب RFC 5996. تم تحديثه بموجب RFC 5282. يُلغي RFC 2407 و 2409 و 2408 .   
  15. ↑ س. ساكان؛ ك. كامادا؛ م. توماس؛ ج. فيلهوبر (مارس 2006). التفاوض على مفاتيح الإنترنت باستخدام بروتوكول كيربر (KINK) . مجموعة عمل الشبكة. doi : 10.17487/RFC4430 . RFC 4430 .المعيار المقترح.
  16. 1 2 م. ريتشاردسون (مارس 2005). طريقة لتخزين بيانات مفاتيح IPsec في نظام أسماء النطاقات (DNS) . مجموعة عمل الشبكة. doi : 10.17487/RFC4025 . RFC 4025 .المعيار المقترح.
  17. ↑ بيتر ويليس (2001). شبكات بروتوكول الإنترنت على نطاق شركات الاتصالات: تصميم وتشغيل شبكات الإنترنت . معهد الهندسة والتكنولوجيا. ص 270. ISBN  9780852969823.
  18. ↑ ر. شيري (أغسطس 2007). معجم أمن الإنترنت، الإصدار 2. مجموعة عمل الشبكة. doi : 10.17487/RFC4949 . RFC 4949 .معلوماتي. يلغي RFC 2828 . 
  19. ↑ إس. كينت (نوفمبر 1991). وزارة الدفاع الأمريكية - خيارات أمنية لبروتوكول الإنترنت . مجموعة عمل الشبكة. doi : 10.17487/RFC1108 . RFC 1108 .تاريخي. عفا عليها الزمن RFC 1038 . 
  20. 1 2 "أرقام البروتوكول" . هيئة الأرقام المخصصة للإنترنت (IANA) . 27-05-2010. مؤرشف من الأصل في 29-05-2010.
  21. ↑ "بروتوكول SIPP لتغليف الحمولة الأمنية" . فريق عمل SIPP التابع لفرقة عمل هندسة الإنترنت (IETF). 1993. مؤرشف من الأصل بتاريخ 9 سبتمبر 2016. تم الاطلاع عليه بتاريخ 7 أغسطس 2013 .
  22. ↑ ديرينغ، ستيف إي. (1993). "مسودة مواصفات SIPP" . IETF. ص 21. 
  23. ↑ بيلوفين، ستيفن م. (1996). "مواضع المشاكل في بروتوكولات أمان بروتوكول الإنترنت" ( PostScript ) . وقائع ندوة Usenix السادسة لأمن أنظمة يونكس . سان خوسيه، كاليفورنيا. الصفحات 1-16 . تاريخ الاسترجاع: 9 يوليو 2007 . 
  24. ↑ باترسون، كينيث ج.؛ ياو، أرنولد ك. ل. (24 أبريل 2006). "التشفير نظريًا وعمليًا: حالة التشفير في بروتوكول أمان الإنترنت (IPsec)" (ملف PDF) . مؤتمر يورو كريبت 2006، سلسلة محاضرات في علوم الحاسوب، المجلد 4004. برلين. الصفحات 12-29 . تاريخ الاطلاع: 13 أغسطس 2007 . 
  25. ↑ ديغابرييل، جان بول؛ باترسون، كينيث ج. (9 أغسطس/آب 2007). "مهاجمة معايير IPsec في تكوينات التشفير فقط" (ملف PDF) . ندوة IEEE حول الأمن والخصوصية، جمعية IEEE للحاسبات . أوكلاند، كاليفورنيا. الصفحات 335-349 . تاريخ الاسترجاع : 13 أغسطس /آب 2007 . 
  26. 1 2 إس. كينت (ديسمبر 2005). تغليف بروتوكول الإنترنت لحمولة الأمان . مجموعة عمل الشبكة. doi : 10.17487/RFC4303 . RFC 4303 .المعيار المقترح. يلغي RFC 2406 . 
  27. ↑ بيتر ويليس (2001). شبكات بروتوكول الإنترنت على نطاق شركات الاتصالات: تصميم وتشغيل شبكات الإنترنت . معهد الهندسة والتكنولوجيا. ص 271. ISBN  9780852969823.
  28. ↑ بيتر ويليس (2001). شبكات بروتوكول الإنترنت على نطاق شركات الاتصالات: تصميم وتشغيل شبكات الإنترنت . معهد الهندسة والتكنولوجيا. الصفحات 272-273 . رقم ISBN  9780852969823.
  29. ↑ م. توماس (يونيو 2001). متطلبات التفاوض على المفاتيح عبر الإنترنت باستخدام بروتوكول Kerberos . مجموعة عمل الشبكة. doi : 10.17487/RFC3129 . RFC 3129 .لأغراض إعلامية.
  30. ↑ سي. كريمرز (2011). "إعادة النظر في تبادل المفاتيح في بروتوكول IPsec: تحليل رسمي لبروتوكولي IKEv1 وIKEv2" . تبادل المفاتيح في بروتوكول IPsec: تحليل رسمي لبروتوكولي IKEv1 وIKEv2، ESORICS 2011. سلسلة محاضرات في علوم الحاسوب. المجلد 6879. سبرينغر. الصفحات 315-334 . doi : 10.1007/978-3-642-23822-2_18 . hdl : 20.500.11850/69608 . ISBN   9783642238222. S2CID 18222662 . 
  31. ↑ ويليام، س.، وستالينغز، و. (2006). التشفير وأمن الشبكات، الطبعة الرابعة. بيرسون للتعليم الهند. ص 492-493
  32. ↑ بيتر ويليس (2001). شبكات بروتوكول الإنترنت على نطاق شركات الاتصالات: تصميم وتشغيل شبكات الإنترنت . معهد الهندسة والتكنولوجيا. ص 266. ISBN  9780852969823.
  33. ↑ بيتر ويليس (2001). شبكات بروتوكول الإنترنت على نطاق شركات الاتصالات: تصميم وتشغيل شبكات الإنترنت . معهد الهندسة والتكنولوجيا. ص 267. ISBN  9780852969823.
  34. ↑ RFC 2367، واجهة برمجة تطبيقات إدارة المفاتيح PF_KEYv2 ، دان ماكدونالد، باو فان، وكريج ميتز (يوليو 1998)
  35. ↑ حمد، محمد؛ بريفيلاكس، فاسيليس (2015). "تنفيذ وتقييم أداء بروتوكول IPsec المدمج في نظام تشغيل النواة المصغرة". المؤتمر العالمي لشبكات الحاسوب وأمن المعلومات 2015 (WSCNIS) . معهد مهندسي الكهرباء والإلكترونيات. الصفحات 1-7 . doi : 10.1109/wscnis.2015.7368294 . ISBN  9781479999064. S2CID 16935000 . 
  36. ↑ إي. جانكيويتش؛ ج. لوغني؛ ت. نارتن (ديسمبر 2011). متطلبات عقدة IPv6 . فريق عمل هندسة الإنترنت . doi : 10.17487/RFC6434 . ISSN 2070-1721 . RFC 6434 . مُلغى. تم إلغاؤه بموجب RFC 8504. يُلغي RFC 4294 .  
  37. ↑ "ميثاق الأمن السيبراني" . تم الاطلاع عليه بتاريخ 26-10-2015 .
  38. ↑ "حالة ipsecme" . تم الاطلاع عليه بتاريخ 26-10-2015 .
  39. ↑ "وثائق سرية تكشف حملة وكالة الأمن القومي ضد التشفير" . صحيفة نيويورك تايمز .
  40. ↑ جون جيلمور. "ردًا على: [ التشفير ] مناقشة افتتاحية: تكهنات حول "بولران"" .
  41. ^ ثيو دي رادت. "الادعاءات المتعلقة بـ OpenBSD IPSEC" .
  42. ↑ جيسون رايت. "ادعاءات تتعلق ببروتوكول IPSEC في نظام OpenBSD" .
  43. ^ ثيو دي رادت (22 ديسمبر 2010). "تحديث بشأن ادعاء الباب الخلفي لـ OpenBSD IPSEC" .
  44. 1 2 أدريان، ديفيد؛ بهارجافان، كارتيكيان؛ دوروميريك، زاكير؛ جودري، بييريك؛ جرين، ماثيو؛ هالدرمان، ج. أليكس؛ هينينجر، ناديا؛ سبرينجال، درو؛ ثومي، إيمانويل؛ فالينتا، لوك؛ فانديرسلوت، بنجامين؛ وسترو، إريك؛ زانيلا-بيجولين، سانتياغو؛ زيمرمان، بول (2015). "السرية الأمامية غير الكاملة" . وقائع المؤتمر الثاني والعشرين لجمعية ACM SIGSAC حول أمن الحاسوب والاتصالات . الصفحات 5-17 . doi : 10.1145/2810103.2813707 . ISBN  9781450338325. S2CID 347988 . 
  45. ↑ غودين، دان (16 أغسطس/آب 2016). "تأكيد: تسريب أداة اختراق جاء من مجموعة "قادرة على كل شيء" مرتبطة بوكالة الأمن القومي" . آرس تكنيكا . تم الاطلاع عليه في 19 أغسطس/آب 2016 .
  46. ↑ تومسون، إيان (17 أغسطس/آب 2016). "سيسكو تؤكد أن اثنين من ثغرات "وكالة الأمن القومي" لدى مجموعة شادو بروكرز حقيقية" . ذا ريجستر . تاريخ الاسترجاع: 16 سبتمبر/أيلول 2016 .
  47. ↑ باولي، دارين (24 أغسطس 2016). "استغلال ثغرة مجموعة Equation يصيب أجهزة Cisco ASA وJuniper Netscreen الأحدث" . ذا ريجستر . تم الاطلاع عليه في 16 سبتمبر 2016 .
  48. ↑ تشيرجوين، ريتشارد (18 أغسطس 2016). "فورتينت تحذو حذو سيسكو في تأكيد ثغرة شادو بروكر" . ذا ريجستر . تم الاطلاع عليه في 16 سبتمبر 2016 .
  49. ↑ "ما نعرفه عن الثغرات التي تم تسريبها في عملية اختراق مرتبطة بوكالة الأمن القومي" . فايس ميديا. 2016. مؤرشف من الأصل بتاريخ 21-06-2023 . تم الاطلاع عليه بتاريخ 22-04-2026 .
  50. ↑ "تبادل المفاتيح - ما هي مشاكل الوضع العدواني لبروتوكول IKEv1 (مقارنةً بالوضع الرئيسي لبروتوكول IKEv1 أو بروتوكول IKEv2)؟" . Cryptography Stack Exchange .
  51. ↑ "لا تتوقف عن استخدام بروتوكول IPsec الآن" . نو هاتس . 29 ديسمبر 2014.

للمزيد من القراءة

مسار المعايير

  • RFC 1829 : تحويل ESP DES-CBC 
  • RFC 2403 : استخدام HMAC-MD5-96 ضمن ESP و AH 
  • RFC 2404 : استخدام HMAC-SHA-1-96 ضمن ESP و AH 
  • RFC 2405 : خوارزمية تشفير ESP DES-CBC مع متجه تهيئة صريح 
  • RFC 2410 : خوارزمية التشفير NULL واستخدامها مع IPsec 
  • RFC 2451 : خوارزميات تشفير وضع CBC لـ ESP 
  • RFC 2857 : استخدام HMAC-RIPEMD-160-96 ضمن ESP و AH 
  • RFC 3526 : مجموعات ديفي-هيلمان الأسية المعيارية الأكثر (MODP) لتبادل مفاتيح الإنترنت (IKE) 
  • RFC 3602 : خوارزمية تشفير AES-CBC واستخدامها مع IPsec 
  • RFC 3686 : استخدام وضع العداد لمعيار التشفير المتقدم (AES) مع حمولة الأمان المغلفة لبروتوكول IPsec (ESP) 
  • RFC 3947 : التفاوض على اجتياز NAT في IKE 
  • RFC 3948 : تغليف حزم بروتوكول أمان الإنترنت (EPS) باستخدام بروتوكول UDP 
  • RFC 4106 : استخدام وضع Galois/Counter (GCM) في IPsec Encapsulating Security Payload (ESP) 
  • RFC 4301 : بنية الأمان لبروتوكول الإنترنت 
  • RFC 4302 : رأس مصادقة IP 
  • RFC 4303 : حمولة أمان مغلفة ببروتوكول الإنترنت 
  • RFC 4304 : ملحق رقم التسلسل الموسع (ESN) لنطاق تفسير بروتوكول أمان الإنترنت (DOI) لبروتوكول إدارة مفاتيح ورابطة أمان الإنترنت (ISAKMP) 
  • RFC 4307 : خوارزميات التشفير المستخدمة في تبادل مفاتيح الإنترنت الإصدار 2 ( IKEv2 ) 
  • RFC 4308 : مجموعات التشفير لبروتوكول IPsec 
  • RFC 4309 : استخدام وضع CCM لمعيار التشفير المتقدم (AES) مع حمولة الأمان المغلفة لبروتوكول IPsec (ESP) 
  • RFC 4543 : استخدام رمز مصادقة رسائل جالوا (GMAC) في بروتوكول IPsec ESP و AH 
  • RFC 4555 : بروتوكول التنقل والتعددية IKEv2 (MOBIKE) 
  • RFC 4806 : امتدادات بروتوكول حالة الشهادة عبر الإنترنت (OCSP) لبروتوكول IKEv2 
  • RFC 4868 : استخدام HMAC-SHA-256 وHMAC-SHA-384 وHMAC-SHA-512 مع IPsec 
  • RFC 4945 : ملف تعريف البنية التحتية للمفاتيح العامة لأمن بروتوكول الإنترنت IKEv1/ISAKMP و IKEv2 و PKIX 
  • RFC 5280 : ملف تعريف شهادة البنية التحتية للمفتاح العام X.509 للإنترنت وقائمة إبطال الشهادات (CRL) 
  • RFC 5282 : استخدام خوارزميات التشفير الموثقة مع الحمولة المشفرة لبروتوكول تبادل مفاتيح الإنترنت الإصدار 2 (IKEv2) 
  • RFC 5386 : أمان أفضل من لا شيء: نمط غير مصادق عليه من بروتوكول IPsec 
  • RFC 5529 : أوضاع تشغيل كاميليا للاستخدام مع بروتوكول IPsec 
  • RFC 5685 : آلية إعادة التوجيه لبروتوكول تبادل مفاتيح الإنترنت الإصدار 2 (IKEv2) 
  • RFC 5723 : استئناف جلسة بروتوكول تبادل مفاتيح الإنترنت الإصدار 2 (IKEv2) 
  • RFC 5857 : امتدادات IKEv2 لدعم ضغط الرأس القوي عبر IPsec 
  • RFC 5858 : امتدادات IPsec لدعم ضغط الرأس القوي عبر IPsec 
  • RFC 7296 : بروتوكول تبادل مفاتيح الإنترنت الإصدار 2 (IKEv2) 
  • RFC 7321 : متطلبات تنفيذ خوارزمية التشفير وإرشادات الاستخدام لتغليف حمولة الأمان (ESP) ورأس المصادقة (AH) 
  • RFC 7383 : تجزئة رسائل بروتوكول تبادل مفاتيح الإنترنت الإصدار 2 (IKEv2) 
  • RFC 7427 : مصادقة التوقيع في تبادل مفاتيح الإنترنت الإصدار 2 (IKEv2) 
  • RFC 7634 : ChaCha20 و Poly1305 واستخدامهما في بروتوكول تبادل مفاتيح الإنترنت (IKE) و IPsec 

نماذج RFC تجريبية

  • RFC 4478 : المصادقة المتكررة في بروتوكول تبادل مفاتيح الإنترنت (IKEv2) 

طلبات التعليقات الإعلامية

  • RFC 2367 : واجهة PF_KEY 
  • RFC 2412 : بروتوكول تحديد مفتاح أوكلي 
  • RFC 3706 : طريقة تعتمد على حركة البيانات للكشف عن نظراء تبادل مفاتيح الإنترنت (IKE) المعطلين 
  • RFC 3715 : متطلبات التوافق بين بروتوكول IPsec وترجمة عناوين الشبكة (NAT) 
  • RFC 4621 : تصميم بروتوكول التنقل والتعددية في بروتوكول IKEv2 (MOBIKE) 
  • RFC 4809 : متطلبات ملف تعريف إدارة شهادات IPsec 
  • RFC 5387 : بيان المشكلة وإمكانية التطبيق لأمن أفضل من لا شيء (BTNS) 
  • RFC 5856 : دمج ضغط الرأس القوي عبر ارتباطات أمان IPsec 
  • RFC 5930 : استخدام وضع عداد معيار التشفير المتقدم (AES-CTR) مع بروتوكول تبادل مفاتيح الإنترنت الإصدار 2 (IKEv2) 
  • RFC 6027 : بيان مشكلة مجموعة IPsec 
  • RFC 6071 : خارطة طريق وثائق IPsec و IKE 
  • RFC 6379 : مجموعة التشفير B لبروتوكول IPsec 
  • RFC 6380 : ملف تعريف المجموعة B لأمن بروتوكول الإنترنت (IPsec) 
  • RFC 6467 : إطار عمل كلمة المرور الآمنة لتبادل مفاتيح الإنترنت الإصدار 2 (IKEv2) 

أفضل الممارسات الحالية في طلبات التعليقات (RFCs)

  • RFC 5406 : إرشادات لتحديد استخدام بروتوكول IPsec الإصدار 2 

طلبات التعليقات القديمة/التاريخية

  • RFC 1825 : بنية الأمان لبروتوكول الإنترنت (تم إلغاؤها بواسطة RFC 2401) 
  • RFC 1826 : رأس مصادقة IP (تم إلغاؤه بواسطة RFC 2402) 
  • RFC 1827 : حمولة الأمان المغلفة لبروتوكول الإنترنت (ESP) (تم إلغاؤها بواسطة RFC 2406) 
  • RFC 1828 : مصادقة IP باستخدام MD5 المفتاحي (تاريخي) 
  • RFC 2401 : بنية الأمان لبروتوكول الإنترنت (نظرة عامة على IPsec) (تم إلغاؤها بواسطة RFC 4301) 
  • RFC 2406 : حمولة الأمان المغلفة لبروتوكول الإنترنت (ESP) (تم إلغاؤها بواسطة RFC 4303 و RFC 4305) 
  • RFC 2407 : نطاق تفسير أمان بروتوكول الإنترنت لبروتوكول ISAKMP (تم إلغاؤه بواسطة RFC 4306) 
  • RFC 2409 : تبادل مفاتيح الإنترنت (تم إلغاؤه بواسطة RFC 4306) 
  • RFC 4305 : متطلبات تنفيذ خوارزمية التشفير لتغليف حمولة الأمان (ESP) ورأس المصادقة (AH) (تم إلغاؤها بواسطة RFC 4835) 
  • RFC 4306 : بروتوكول تبادل مفاتيح الإنترنت (IKEv2) (تم إلغاؤه بواسطة RFC 5996) 
  • RFC 4718 : توضيحات وإرشادات تنفيذ IKEv2 (تم إلغاؤها بواسطة RFC 7296) 
  • RFC 4835 : متطلبات تنفيذ خوارزمية التشفير لتغليف حمولة الأمان (ESP) ورأس المصادقة (AH) (تم إلغاؤها بواسطة RFC 7321) 
  • RFC 5996 : بروتوكول تبادل مفاتيح الإنترنت الإصدار 2 (IKEv2) (تم إلغاؤه بواسطة RFC 7296)