بروتوكول الإنترنت الآمن

الموسوعة الحرة
بروتوكول الإنترنت الآمن
أمن بروتوكول الإنترنت
بدأت السنة1996
منظمةفريق عمل هندسة الإنترنت
المعايير الأساسيةمتنوع، راجع فصل وثائق IETF
مجموعة بروتوكولات الإنترنت
طبقة التطبيق
طبقة النقل
طبقة الانترنت
طبقة الارتباط
  • ف
  • ت
  • هـ

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

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

تاريخ

بدءًا من أوائل سبعينيات القرن العشرين، رعت وكالة مشاريع الأبحاث المتقدمة سلسلة من أجهزة تشفير ARPANET التجريبية ، في البداية لتشفير حزم ARPANET الأصلية ثم لتشفير حزم TCP/IP ؛ وقد تم اعتماد بعض هذه الأجهزة واستخدامها. ومن عام 1986 إلى عام 1991، رعت وكالة الأمن القومي تطوير بروتوكولات الأمان للإنترنت في إطار برنامج أنظمة شبكات البيانات الآمنة (SDNS). [2] وقد جمع هذا العديد من البائعين بما في ذلك موتورولا التي أنتجت جهاز تشفير الشبكة في عام 1988. وقد نُشر العمل علنًا منذ حوالي عام 1988 بواسطة المعهد الوطني للمعايير والتكنولوجيا ، ومن بين هذه الأجهزة، تحول بروتوكول الأمان في الطبقة 3 (SP3) في النهاية إلى بروتوكول أمان طبقة الشبكة القياسي (NLSP) التابع لمنظمة ISO. [3]

في عام 1992، تم تمويل مختبر أبحاث البحرية الأمريكية (NRL) من قبل DARPA CSTO لتنفيذ IPv6 ولإجراء البحوث وتنفيذ تشفير IP في 4.4 BSD ، ودعم كل من معماريات SPARC وx86 CPU. جعلت DARPA تنفيذه متاحًا مجانًا عبر MIT. في إطار جهود البحث الممولة من DARPA في NRL ، طور NRL مواصفات مسار معايير IETF (RFC 1825 حتى RFC 1827) لـ IPsec. [4] تم وصف تنفيذ IPsec الخاص بـ NRL في ورقتهم في وقائع مؤتمر USENIX لعام 1996. [5] تم توفير تنفيذ IPsec مفتوح المصدر الخاص بـ NRL عبر الإنترنت بواسطة MIT وأصبح الأساس لمعظم التطبيقات التجارية الأولية. [4]

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

هندسة الأمن

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

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

رأس المصادقة

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

تم تطوير رأس المصادقة الأمني ​​(AH) في مختبر أبحاث البحرية الأمريكية في أوائل التسعينيات وهو مشتق جزئيًا من عمل معايير IETF السابقة للمصادقة على بروتوكول إدارة الشبكة البسيط (SNMP) الإصدار 2. رأس المصادقة (AH) هو عضو في مجموعة بروتوكولات IPsec. يضمن رأس المصادقة الأمان سلامة عدم الاتصال باستخدام دالة تجزئة ومفتاح مشترك سري في خوارزمية رأس المصادقة. يضمن رأس المصادقة الأمان أيضًا أصل البيانات عن طريق مصادقة حزم 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 معظم رأس قاعدة IPv6، وAH نفسها، ورؤوس الامتداد غير القابلة للتغيير بعد AH، وحمولة IP. تستبعد الحماية لرأس IPv6 الحقول القابلة للتغيير: DSCP و ECN وFlow Label وHope Limit. [11]

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

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

تنسيق رأس المصادقة
الإزاحة ثماني بتات 0 1 2 3
ثماني بتات قليل 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 العنوان التالي حمولة لين محجوز
4 32 مؤشر معلمات الأمان
8 64 رقم التسلسل
12 96 قيمة فحص النزاهة
⋮ ⋮
العنوان التالي: 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 Encapsulating Security Payload (ESP) في أوضاع النفق والنقل

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

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

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

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

تغليف تنسيق الحمولة الأمنية
الإزاحة ثماني بتات 0 1 2 3
ثماني بتات قليل 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
0 0 مؤشر معلمات الأمان
4 32 رقم التسلسل
8 64 بيانات الحمولة
⋮ ⋮
⋮ ⋮    
⋮ ⋮ (حشوة)
⋮ ⋮   طول الوسادة العنوان التالي
⋮ ⋮ قيمة فحص النزاهة
⋮
⋮ ⋮
مؤشر معلمات الأمان  (SPI): 32 بت
قيمة عشوائية مستخدمة (مع عنوان IP الوجهة) لتحديد ارتباط الأمان للطرف المتلقي.
رقم التسلسل: 32 بت
رقم تسلسلي متزايد بشكل رتيب (يزداد بمقدار 1 لكل حزمة يتم إرسالها) للحماية من هجمات الإعادة . يوجد عداد منفصل يتم الاحتفاظ به لكل ارتباط أمني.
بيانات الحمولة: متغيرة
المحتويات المحمية لحزمة IP الأصلية، بما في ذلك أي بيانات مستخدمة لحماية المحتويات (على سبيل المثال، متجه تهيئة لخوارزمية التشفير). يتم الإشارة إلى نوع المحتوى الذي تمت حمايته بواسطة حقل العنوان التالي .
الحشو: 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)، والتفاوض على المفاتيح عبر الإنترنت باستخدام Kerberized (KINK)، واستخدام سجلات DNS الخاصة بـ IPSECKEY . [16] [1] : §1  [29] يحدد RFC 5386 الأمان الأفضل من لا شيء (BTNS) كوضع غير مصدق لـ IPsec باستخدام بروتوكول IKE ممتد. استخدم C. Meadows وC. Cremers وآخرون طرقًا رسمية لتحديد الشذوذ المختلفة الموجودة في IKEv1 وأيضًا في IKEv2. [30]

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

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

حافظ على الحياة

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

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

UDP keepalive هو بديل لـ DPD.

طرق التشغيل

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

أوضاع IPsec

وضع النقل

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

تم تعريف وسيلة لتغليف رسائل IPsec لاجتياز NAT {NAT-T} بواسطة مستندات RFC التي تصف آلية NAT-T.

وضع النفق

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

يدعم وضع النفق عبور NAT.

الخوارزميات

خوارزميات التشفير المتماثل

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

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

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

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

التنفيذات

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

عندما يتم تنفيذ IPsec في النواة ، يتم تنفيذ إدارة المفاتيح والتفاوض على ISAKMP / IKE من مساحة المستخدم. غالبًا ما يتم استخدام "PF_KEY Key Management API، الإصدار 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 محل هذه المستندات مع بعض التفاصيل الهندسية غير المتوافقة، على الرغم من أنها كانت متطابقة من الناحية المفاهيمية. بالإضافة إلى ذلك، تم تعريف بروتوكول تبادل المفاتيح والمصادقة المتبادلة Internet Key Exchange (IKE) لإنشاء وإدارة ارتباطات الأمان. في ديسمبر 2005، تم تعريف معايير جديدة في RFC 4301 وRFC 4309 والتي تعد إلى حد كبير مجموعة فرعية من الإصدارات السابقة مع إصدار ثانٍ من معيار تبادل المفاتيح عبر الإنترنت IKEv2 . قامت هذه المستندات من الجيل الثالث بتوحيد اختصار IPsec إلى "IP" بأحرف كبيرة و"sec" بأحرف صغيرة. يشير "ESP" عمومًا إلى RFC 4303، وهو أحدث إصدار من المواصفات.

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

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

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

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

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

كان التفسير البديل الثاني الذي تم طرحه هو أن مجموعة Equation استخدمت ثغرات اليوم صفر ضد معدات VPN الخاصة بالعديد من الشركات المصنعة والتي تم التحقق من صحتها من قبل Kaspersky Lab على أنها مرتبطة بمجموعة Equation [45] وتم التحقق من صحتها من قبل تلك الشركات المصنعة على أنها ثغرات حقيقية، بعضها كانت ثغرات اليوم صفر في وقت تعرضها. [46] [47] [48] كانت جدران الحماية Cisco PIX وASA بها ثغرات تم استخدامها للتنصت من قبل وكالة الأمن القومي [ بحاجة لمصدر ] .

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

انظر أيضا

مراجع

  1. ^ abc D. Harkins; R. Atkinson (نوفمبر 1998). IP Encapsulating Security Payload (ESP). Network Working Group. doi : 10.17487/RFC2406 . RFC 2406. عفا عليها الزمن. تم إلغاؤه بموجب RFC 4303 و4305. أصبح عفا عليها الزمن بموجب RFC 1827.
  2. ^ دال، هيتيش؛ دال، دوللي؛ باترا، سونيا؛ راني، بوجا (2012). "تنفيذ بروتوكول IPSec". المؤتمر الدولي الثاني لعام 2012 حول تقنيات الحوسبة والاتصالات المتقدمة . معهد مهندسي الكهرباء والإلكترونيات . ص 176-181. doi :10.1109/ACCT.2012.64. ISBN 978-1-4673-0471-9. S2CID  16526652.
  3. ^ جيلمور، جون. "تشفير الشبكة – التاريخ وبراءات الاختراع". مؤرشف من الأصل في 2014-09-03 . تم استرجاعه في 2014-02-18 .
  4. ^ أ ب “صفحة توزيع IPv6 + IPSEC + ISAKMP”. web.mit.edu .
  5. ^ "المؤتمر الفني السنوي لـ USENIX 1996". www.usenix.org .
  6. ^ "بروتوكول أمان IP (ipsec) -". datatracker.ietf.org .
  7. ^ S. Kent ؛ K. Seo (ديسمبر 2005). هندسة الأمان لبروتوكول الإنترنت. مجموعة عمل الشبكة. doi : 10.17487/RFC4301 . RFC 4301. المعيار المقترح. ص. 4. أصبح معيار RFC 2401 قديمًا. تم تحديثه بواسطة RFC 6040 و7619. يُفضَّل استخدام التهجئة "IPsec" في هذا المعيار وجميع معايير IPsec ذات الصلة. أصبحت جميع الأحرف الكبيرة الأخرى لـ IPsec [...] قديمة.
  8. ^ "إنجازات قسم تكنولوجيا المعلومات في المختبر الوطني للبحوث البحرية - IPSec وIPv6" (ملف PDF) . مختبرات البحوث البحرية الأمريكية . مؤرشف من الأصل (ملف PDF) في 2015-09-15.
  9. ^ S. Frankel; S. Krishnan (فبراير 2011). خريطة طريق وثيقة أمان بروتوكول الإنترنت (IPsec) وتبادل مفاتيح الإنترنت (IKE). فريق عمل هندسة الإنترنت (IETF). doi : 10.17487/RFC6071 . ISSN  2070-1721. RFC 6071. إعلامي. يجعل RFC 2411 قديمًا .
  10. ^ P. Hoffman (ديسمبر 2005). مجموعات التشفير لـ IPsec. مجموعة عمل الشبكة. doi : 10.17487/RFC4308 . RFC 4308. المعيار المقترح.
  11. ^ abcde S. Kent (ديسمبر 2005). IP Authentication Header. Network Working Group. doi : 10.17487/RFC4302 . RFC 4302. المعيار المقترح يلغي الحاجة إلى RFC 2402.
  12. ^ تبادل المفاتيح عبر الإنترنت (IKE)، RFC 2409، §1 الملخص
  13. ^ S. Kent ؛ D. Carrel (نوفمبر 1998). تبادل المفاتيح عبر الإنترنت (IKE). مجموعة عمل الشبكة. doi : 10.17487/RFC2409 . RFC 2409. عفا عليها الزمن. تم إلغاؤه بموجب RFC 4306. تم تحديثه بموجب RFC 4109.
  14. ^ C. Kaufman (ديسمبر 2005). بروتوكول تبادل المفاتيح عبر الإنترنت (IKEv2). مجموعة عمل الشبكة. doi : 10.17487/RFC4306 . RFC 4306. عفا عليها الزمن. تم إلغاؤه بموجب RFC 5996. تم تحديثه بموجب RFC 5282. أصبح RFC 2407 و2409 و2408 قديمًا.
  15. ^ S. Sakane; K. Kamada; M. Thomas; J. Vilhuber (مارس 2006). Kerberized Internet Negotiation of Keys (KINK). Network Working Group. doi : 10.17487/RFC4430 . RFC 4430. المعيار المقترح.
  16. ^ ab M. Richardson (مارس 2005). طريقة لتخزين مواد مفاتيح IPsec في DNS. مجموعة عمل الشبكة. doi : 10.17487/RFC4025 . RFC 4025. المعيار المقترح.
  17. ^ بيتر ويليس (2001). شبكات بروتوكول الإنترنت على نطاق الناقل: تصميم وتشغيل شبكات الإنترنت . IET. ص 270. ISBN 9780852969823.
  18. ^ R. Shirey (أغسطس 2007). Internet Security Glossary، الإصدار 2. Network Working Group. doi : 10.17487/RFC4949 . RFC 4949. إعلامي. يجعل RFC 2828 قديمًا .
  19. ^ S. Kent (نوفمبر 1991). وزارة الدفاع الأمريكية - خيارات الأمان لبروتوكول الإنترنت. مجموعة عمل الشبكة. doi : 10.17487/RFC1108 . RFC 1108. تاريخي. يصبح RFC 1038 قديمًا.
  20. ^ "أرقام البروتوكول". IANA . 2010-05-27. مؤرشف من الأصل في 2010-05-29.
  21. ^ "SIPP Encapsulating Security Payload". IETF SIPP Working Group. 1993. مؤرشف من الأصل في 2016-09-09 . تم الاسترجاع في 2013-08-07 .
  22. ^ Deering, Steve E. (1993). "مسودة مواصفات SIPP". IETF. ص 21.
  23. ^ Bellovin, Steven M. (1996). "Problem Areas for the IP Security Protocols" ( PostScript ) . وقائع ندوة Usenix Unix Security Symposium السادسة . سان خوسيه، كاليفورنيا. ص 1-16 . تم الاسترجاع في 9 يوليو 2007 .
  24. ^ باترسون، كينيث جي؛ ياو، أرنولد كيه إل (2006-04-24). "التشفير في النظرية والتطبيق: حالة التشفير في IPsec" (PDF) . يوروكريبت 2006، محاضرات في علوم الكمبيوتر المجلد 4004. برلين. ص 12-29 . تم الاسترجاع في 2007-08-13 .
  25. ^ Degabriele, Jean Paul; Paterson, Kenneth G. (2007-08-09). "Attacking the IPsec Standards in Encryption-only Configurations" (PDF) . ندوة معهد مهندسي الكهرباء والإلكترونيات حول الأمن والخصوصية، جمعية الحاسبات التابعة لمعهد مهندسي الكهرباء والإلكترونيات . أوكلاند، كاليفورنيا. ص 335-349 . تم الاسترجاع في 2007-08-13 .
  26. ^ ab S. Kent (ديسمبر 2005). IP Encapsulating Security Payload. Network Working Group. doi : 10.17487/RFC4303 . RFC 4303. المعيار المقترح يلغي الحاجة إلى RFC 2406.
  27. ^ بيتر ويليس (2001). شبكات بروتوكول الإنترنت على نطاق الناقل: تصميم وتشغيل شبكات الإنترنت . IET. ص 271. ISBN 9780852969823.
  28. ^ بيتر ويليس (2001). شبكات بروتوكول الإنترنت على نطاق الناقل: تصميم وتشغيل شبكات الإنترنت . IET. ص 272-273. ISBN 9780852969823.
  29. ^ M. Thomas (يونيو 2001). متطلبات التفاوض على المفاتيح عبر الإنترنت باستخدام Kerberized. مجموعة عمل الشبكة. doi : 10.17487/RFC3129 . RFC 3129. إعلامية.
  30. ^ C. Cremers (2011). Key Exchange in IPsec Revisited: Formal Analysis of IKEv1 and IKEv2, ESORICS 2011. Lecture Notes in Computer Science. Springer. pp. 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). شبكات بروتوكول الإنترنت على نطاق الناقل: تصميم وتشغيل شبكات الإنترنت . IET. ص 266. ISBN 9780852969823.
  33. ^ بيتر ويليس (2001). شبكات بروتوكول الإنترنت على نطاق الناقل: تصميم وتشغيل شبكات الإنترنت . IET. ص 267. ISBN 9780852969823.
  34. ^ RFC 2367، واجهة برمجة تطبيقات إدارة المفاتيح PF_KEYv2 ، دان ماكدونالد، وباو فان، وكريج ميتز (يوليو 1998)
  35. ^ حمد، محمد؛ بريفيلاكيس، فاسيليس (2015). "تنفيذ وتقييم أداء IPsec المضمن في أنظمة تشغيل النواة الدقيقة". ندوة عالمية حول شبكات الكمبيوتر وأمن المعلومات (WSCNIS) 2015. معهد مهندسي الكهرباء والإلكترونيات. ص. 1-7. doi :10.1109/wscnis.2015.7368294. ISBN 9781479999064. S2CID  16935000.
  36. ^ RFC 6434، “متطلبات عقدة IPv6”، E. Jankiewicz، J. Loughney، T. Narten (ديسمبر 2011)
  37. ^ "ميثاق ipsecme" . تم الاسترجاع في 2015-10-26 .
  38. ^ "ipsecme status" . تم الاسترجاع في 2015-10-26 .
  39. ^ "وثائق سرية تكشف عن حملة وكالة الأمن القومي ضد التشفير". نيويورك تايمز .
  40. ^ جون جيلمور. "رد: [التشفير] مناقشة افتتاحية: تكهنات حول ""BULLRUN""."
  41. ^ ثيو دي رادت. “الادعاءات المتعلقة بـ OpenBSD IPSEC”.
  42. ^ جيسون رايت. "الادعاءات المتعلقة بـ OpenBSD IPSEC".
  43. ^ ثيو دي رادت. “تحديث بشأن ادعاء الباب الخلفي لـ OpenBSD IPSEC”.
  44. ^ ab Adrian, David; Bhargavan, Karthikeyan; Durumeric, Zakir; Gaudry, Pierrick; Green, Matthew; Halderman, J. Alex; Heninger, Nadia; Springall, Drew; Thomé, Emmanuel; Valenta, Luke; Vandersloot, Benjamin; Wustrow, Eric; Zanella-Béguelin, Santiago; Zimmermann, Paul (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). "استغلال مجموعة المعادلات يضرب أجهزة Cisco ASA وJuniper Netscreen الأحدث". The Register . تم الاسترجاع في 16 سبتمبر 2016 .
  48. ^ تشيرغوين، ريتشارد (18 أغسطس 2016). "فورتينيت تتبع سيسكو في تأكيد ثغرة Shadow Broker". The Register . تم الاسترجاع في 16 سبتمبر 2016 .
  49. ^ "تبادل المفاتيح - ما هي مشاكل الوضع العدواني IKEv1 (مقارنة بالوضع الرئيسي IKEv1 أو IKEv2)؟". Cryptography Stack Exchange .
  50. ^ "لا تتوقف عن استخدام IPsec بعد". No Hats . 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 مع Explicit IV
  • RFC 2410: خوارزمية تشفير NULL واستخدامها مع IPsec
  • RFC 2451: خوارزميات التشفير في وضع ESP CBC
  • RFC 2857: استخدام HMAC-RIPEMD-160-96 داخل ESP وAH
  • RFC 3526: مجموعات Diffie-Hellman الأسيّة المعيارية (MODP) لتبادل المفاتيح عبر الإنترنت (IKE)
  • RFC 3602: خوارزمية تشفير AES-CBC واستخدامها مع IPsec
  • RFC 3686: استخدام وضع العداد لمعيار التشفير المتقدم (AES) مع الحمولة الأمنية المغلفة لـ IPsec (ESP)
  • RFC 3947: التفاوض على NAT-Traversal في IKE
  • RFC 3948: تغليف UDP لحزم IPsec ESP
  • RFC 4106: استخدام وضع Galois/Counter (GCM) في الحمولة الأمنية المغلفة لـ IPsec (ESP)
  • RFC 4301: هندسة الأمان لبروتوكول الإنترنت
  • RFC 4302: رأس مصادقة IP
  • RFC 4303: حمولة الأمان المغلفة بـ IP
  • RFC 4304: ملحق رقم التسلسل الممتد (ESN) لنطاق تفسير IPsec (DOI) لرابطة أمان الإنترنت وبروتوكول إدارة المفاتيح (ISAKMP)
  • RFC 4307: خوارزميات التشفير للاستخدام في تبادل المفاتيح عبر الإنترنت الإصدار 2 ( IKEv2 )
  • RFC 4308: مجموعات التشفير لـ IPsec
  • RFC 4309: استخدام وضع CCM لمعيار التشفير المتقدم (AES) مع الحمولة الأمنية المغلفة لـ IPsec (ESP)
  • RFC 4543: استخدام رمز مصادقة رسالة Galois (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: ملف تعريف PKI لأمن IP على الإنترنت الخاص بـ IKEv1/ISAKMP وIKEv2 وPKIX
  • RFC 5280: ملف تعريف شهادة البنية الأساسية للمفتاح العام لـ Internet X.509 وقائمة إلغاء الشهادات (CRL)
  • RFC 5282: استخدام خوارزميات التشفير المعتمدة مع الحمولة المشفرة لبروتوكول تبادل المفاتيح عبر الإنترنت الإصدار 2 (IKEv2)
  • RFC 5386: الأمان الأفضل من لا شيء: وضع غير مصدق لـ IPsec
  • RFC 5529: طرق تشغيل Camellia للاستخدام مع 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

RFCs التجريبية

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

RFCs المعلوماتية

  • RFC 2367: واجهة PF_KEY
  • RFC 2412: بروتوكول تحديد المفتاح OAKLEY
  • RFC 3706: طريقة تعتمد على حركة المرور للكشف عن نظراء تبادل المفاتيح عبر الإنترنت (IKE) الميتين
  • RFC 3715: متطلبات توافق ترجمة عناوين الشبكة (NAT) مع IPsec
  • RFC 4621: تصميم بروتوكول التنقل والتعدد في المواقع IKEv2 (MOBIKE)
  • RFC 4809: متطلبات ملف تعريف إدارة شهادة IPsec
  • RFC 5387: بيان المشكلة وإمكانية التطبيق للأمن الأفضل من لا شيء (BTNS)
  • RFC 5856: تكامل ضغط الرأس القوي عبر ارتباطات أمان IPsec
  • RFC 5930: استخدام وضع عداد معيار التشفير المتقدم (AES-CTR) مع بروتوكول تبادل المفاتيح عبر الإنترنت الإصدار 02 (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 القديمة/القديمة

  • RFC 1825: بنية الأمان لبروتوكول الإنترنت (تم التخلي عنها بموجب RFC 2401)
  • RFC 1826: رأس مصادقة IP (تم التخلي عنه بواسطة RFC 2402)
  • RFC 1827: حمولة الأمان المغلفة لبروتوكول الإنترنت (ESP) (تم التخلي عنها بواسطة RFC 2406)
  • RFC 1828: مصادقة IP باستخدام Keyed MD5 (تاريخيًا)
  • RFC 2401: هندسة الأمان لبروتوكول الإنترنت (نظرة عامة على IPsec) (تم التخلي عنها بموجب RFC 4301)
  • RFC 2406: حمولة الأمان المغلفة لبروتوكول الإنترنت (ESP) (تم التخلي عنها بموجب RFC 4303 وRFC 4305)
  • RFC 2407: مجال تفسير أمان IP للإنترنت لـ 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)
  • جميع مجموعات عمل الأمان النشطة التابعة لـ IETF
    • مجموعة عمل IETF ipsecme (مجموعة عمل صيانة أمان IP والتوسعات)
    • مجموعة عمل IETF btns (مجموعة عمل "الأمن الأفضل من لا شيء") (مفوضة للعمل على IPsec غير المصدق، وواجهات برمجة تطبيقات IPsec، وإغلاق الاتصال)]
  • تأمين البيانات أثناء نقلها باستخدام IPsec محفوظ في 13 أكتوبر 2008 على موقع Wayback Machine مقالة بقلم Deb Shinder من موقع WindowsSecurity.com
  • IPsec على Microsoft TechNet
    • أداة تشخيص IPsec من Microsoft على مركز التنزيل الخاص بـ Microsoft
  • دليل مصور لـ IPsec بقلم ستيف فريدل
  • هندسة الأمان لاتصالات البيانات عبر بروتوكول الإنترنت (IPsec) محاضرات مانفريد ليندنر الجزء الأول من IPsec
  • إنشاء شبكات VPN باستخدام IPsec وSSL/TLS مقالة في مجلة Linux بقلم رامي روزن
تم الاسترجاع من "https://en.wikipedia.org/w/index.php?title=IPsec&oldid=1252639229"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate