مقترح

1.0 ملخص للمشكلة التي يعالجها هذا الاقتراح

لا تعني السياسة الحالية الالتزام بتسجيل جهة اتصال لإساءة الاستخدام وتحديد تنسيق للاتصال الشخصي و "الإبلاغ التلقائي" ، مقارنةً بالآخرين RIRتصبح الصورة مربكة ، حيث أن البريد الإلكتروني الواحد سيكون أكثر كفاءة ، كما في النهاية ، يتم نسخ التقارير إلى كل من رسائل البريد الإلكتروني.

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

في الممارسة العملية ، تصبح جهة الاتصال هذه غير فعالة للإبلاغ عن الانتهاكات وتؤدي عمومًا إلى مشاكل أمنية وتكاليف للضحايا.

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

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

وبهذه الطريقة ، سيكون اتصال إساءة استخدام AfriNIC متوافقًا مع الآخر RIRس. تستخدم APNIC الآن IRT ، ولكن منذ قبول الاقتراح المكافئ ، سيتم إنشاء "رابط" تلقائي (الاسم المستعار) إلى IRT الموجود مسبقًا ، لذلك تسود abuse-c و abuse-mail.

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

2.0 ملخص عن كيفية معالجة هذا الاقتراح للمشكلة

يعتمد مجتمع الإنترنت على التعاون. ومع ذلك ، في كثير من الحالات ، هذا غير كافٍ ، وعلينا جميعًا أن نكون قادرين على الاتصال بـ LIRs التي قد تواجه مشكلة في شبكاتها وغير مدركة للموقف.

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

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

لهذا ، تصبح سمة abuse-c إلزامية في كائنات "aut-num" و "inetnum" و "inet6num" ، وكذلك في أي أشياء أخرى يمكن استخدامها في المستقبل. هذه السمة هي جهة اتصال لإساءة الاستخدام ، ويجب أن تحتوي على الأقل على سمة "صندوق البريد - الإساءة".

من المتوقع أن يتم تنفيذ الاقتراح خلال 90 يومًا ، لتأكيده من قبل AfriNIC ، وهو إطار زمني معقول للسماح لكل من الموظفين بتطوير الأداة و LIRs لتحديث جهات الاتصال الخاصة بهم بإساءة الاستخدام.

3. الاقتراح 

3.1 تعديل 8.0 من الاجتماع التحضيري للمؤتمر ، على النحو التالي:

3.2 معلومات إضافية:

نظرًا لتنفيذ هذا الاقتراح ، ستنشر AFRINIC IRT كاسم مستعار إلى abuse-c ، من أجل تسهيل البحث في whois للحصول على نفس المعلومات ، بغض النظر عما إذا كنت تبحث عن abuse-c أو IRT. يمكن الاحتفاظ ببقية المعلومات الفعلية الموجودة في IRT وفقًا للإرشادات الفعلية (التي ستحتاج إلى تحديث AFRINIC). يتم ذلك من أجل استيعاب IRT في غالبية RIRليالي حيث هو سوء المعاملة ج. 

مثال على إجراء التحقق من الصحة. 

1. تبدأ AFRINIC عملية التحقق من الصحة تلقائيًا ، حيث ترسل اثنان من رسائل البريد الإلكتروني المتتالية إلى "علبة البريد الخاصة بالإساءة". 

2. سيتم إرسال رسائل البريد الإلكتروني هذه تحتوي على نص عادي فقط.

3. وفقًا لتقدير AFRINIC ، بشكل عام أو في حالات محددة (على سبيل المثال ، للتأكيد في حالات التصعيد أقل من 8.6) ، يجوز لـ AFRINIC استخدام مجالات أخرى بخلاف afrinic. * ، وحتى تعديل موضوع ونص الرسالة. أداء التحقق من صحة وقال أكثر فعالية.

4. ستتضمن رسالة البريد الإلكتروني الأولى عنوان URL الذي يجب إجراء التحقق منه ("validacion.afrinic.net") وقد تحتوي على معلومات حول الإجراء ، وموجز موجز لهذه السياسة ، إلخ.

5. سوف يحتوي البريد الإلكتروني الثاني على رمز تحقق أبجدي رقمي فريد. 

6. يجب على الشخص المسؤول عن "علبة البريد الخاصة بإساءة الاستخدام" الانتقال إلى عنوان URL ولصق الرمز الذي تم استلامه في البريد الإلكتروني الثاني في النموذج.

7. يجب تصميم عنوان URL بطريقة تمنع استخدام عملية تلقائية (على سبيل المثال ، "captcha"). بالإضافة إلى ذلك ، يجب أن يحتوي على نص يؤكد أن الشخص الذي يقوم بالتحقق من الصحة يفهم الإجراء والسياسة ، وأنهم يراقبون بانتظام "صندوق البريد الخاص بالإساءة" ، واتخاذ التدابير اللازمة لحل حالات إساءة الاستخدام المبلغ عنها ، وأن تقرير إساءة الاستخدام يتلقى ردًا ، مع "مربع اختيار" يجب قبوله للمتابعة.

8. سيكون الرمز الأبجدي الرقمي صالحًا لمدة أقصاها 15 يوم عمل. 

9. إذا لم يتم إدخال الرمز في غضون ذلك الوقت ، فسيقوم النظام بوضع علامة "abuse-c" على أنه "غير صالح مؤقتًا" وسوف ينبه موظفي AFRINIC حتى يتمكنوا من بدء متابعة مخصصة مع صاحب المورد.

10. إذا لم يتم تلقي أي رد يؤكد أن الموقف قد تم تصحيحه ، بعد فترة إضافية من 15 يوم عمل ، سيتم وضع علامة "abuse-c" بشكل دائم على أنها "غير صالحة".

11. يجب على AFRINIC التأكد من وضع جميع وسائل "تحذير" صاحب المورد في مكانها الصحيح ، مثل رسائل البريد الإلكتروني الدورية إلى صناديق البريد الإلكتروني الأخرى ، والنوافذ المنبثقة في حالة تأهب ، إلخ. يجب أن تحتوي جميع هذه على نص السياسة والتذكيرات بشأن العواقب في حالة استمرار انتهاك السياسة. وينبغي أيضا النظر في وسائل منع الوصول إلى بعض الخدمات.

12. سيتم تكرار عملية التحقق من الصحة تلقائيًا (البنود من 1 إلى 8 أعلاه). إذا كان مرضًا ، فسيتم تمييز "abuse-c" على أنه "صالح" ؛ وإلا سيتم النظر في انتهاك للسياسة. 

13. يجب أن يكون هناك أدوات مثل نموذج ، صندوق بريد (على سبيل المثال ، صندوق بريد مثل "Abuse-escalation@afrinic.net") ، أو غيرها في المستقبل ، لتصعيد عدم الامتثال لهذه السياسة وحتى للوساطة من قبل AFRINIC ، وعند الاقتضاء ، وتطبيق السياسات / الإجراءات ذات الصلة ، وخاصة تلك المتعلقة بإلغاء الموارد.

مراجع حسابات

تم قبول اقتراح مماثل في APNIC وهو قيد المناقشة في مناطق ARIN و LACNIC و RIPE.

تقييم الموظفين

ملف PDF

1.0 فهم الموظفين للاقتراح

1. نص سياسة الاستبدال إلى CPM 8.0 الحالي (معلومات جهة اتصال إساءة الاستخدام) - [القسم 8.1]
2. يقدم سمة "abuse-c" إلزامية في inetnum و inet6num و aut-num whois كائنات قاعدة البيانات. قيمة هذه السمة هي عنوان بريد إلكتروني (صندوق بريد إساءة) ، يتم إرسال جميع المعلومات المتعلقة بإساءة الاستخدام إليه. يُعد صندوق البريد الإلكتروني المسيء اختياريًا في الكائنات التابعة للتخصيصات أو التعيينات الأصلية المباشرة الصادرة عن AFRINIC - [القسم 8.2]
3. يجب أن يكون صندوق بريد إساءة الاستخدام صالحًا ويتم مراقبته بنشاط من خلال التحقق من الفترة - [القسم 8.2]
4. يجب أن يحتاج البريد الإلكتروني المرسل إلى صندوق بريد إساءة الاستخدام إلى تدخل يدوي من قبل المستلم في مرحلة ما- [القسم 8.3]
5. يجب على AFRINIC توفير نظام للتحقق من صحة صندوق بريد إساءة الاستخدام. تُترك العملية الفعلية لتقدير موظفي AFRINIC ، ولكن يمكن أن تتبع مثالاً للإجراء الوارد في القسم 3.2 من اقتراح السياسة ، مع الحد الأدنى الموصى به للفاصل الزمني للتحقق مرة واحدة على الأقل كل 6 أشهر - [القسم 8.4]
6. ستؤدي علب البريد Abuse-c التي تفشل في اختبارات التحقق من الصحة إلى الحظر النهائي لخدمات معينة ، وفقًا لتقدير AFRINIC (ووفقًا للسياسات / الإجراءات ذات الصلة) - [القسم 8.5]
7. يجب توفير آلية تصعيد إلى AFRINIC حيث يمكن الإبلاغ عن أي مخاوف تتعلق بعملية التحقق من قبل المجتمع و / أو الأعضاء. يمكن أن يساعد هذا أيضًا في عمليات إعادة التحقق اليدوية. - [القسم 8.6]

2.0 تعليقات الموظفين

1. يوجد بالفعل حل موجود من خلال كائن IRT ، وهو اختياري حاليًا - (والذي يبدو أنه يعالج الغرض من الاقتراح) - والذي يمكن جعله إلزاميًا لكائنات الموارد التي تم إصدارها مباشرةً بواسطة AFRINIC. ميزة إضافية لاستخدام IRT هي أنه يمكن أن يحتوي على معلومات أكثر من مجرد عنوان بريد إلكتروني ، مثل العنوان الفعلي وأرقام الهواتف ومفاتيح PGP للاتصال الآمن. 
2. خلال اجتماع السياسة العامة AFRINIC30 ، أوضح المؤلف أن IRT يمكن أن يكون "اسمًا مستعارًا" لإساءة استخدام c. ومع ذلك ، نلاحظ أنه من المربك استخدام IRT كاسم مستعار لـ abuse-c والعكس صحيح - لن نعرف كيفية تنفيذ مثل هذا المطلب ما لم يوجه المؤلف بمواصفات مفصلة من خلال اقتراح السياسة أو من خلال (DBWG ) مجموعة عمل قاعدة البيانات.
3. في 8.5 المقترح حيث ستؤدي علب البريد إساءة-c التي تفشل في اختبارات التحقق من الصحة إلى الحظر النهائي لخدمات معينة ، وفقًا لتقدير AFRINIC (ووفقًا للسياسات / الإجراءات ذات الصلة). يجب أن يكون اقتراح السياسة واضحًا بشأن الخدمات المحددة التي سيتم حظرها. ومع ذلك ، من المهم ملاحظة أنه بدون هذا البند في المقام الأول ، فإن خرق السياسة (مثل عدم وجود إساءة استخدام صالحة - ج إذا تم تمرير هذا الاقتراح) يرقى إلى انتهاك RSA ، والذي يمكن أن يؤدي في نهاية المطاف إلى إلغاء نفس RSA والخدمات المرتبطة بها.

3.0 ملاحظات قانونية 

بدون سلوفان

• التنفيذ:
• الجدول الزمني والأثر: حوالي 6 أشهر من أعمال تطوير البرمجيات.
• متطلبات التنفيذ: تعديلات على WHOIS قاعدة البيانات بناءً على الحل الذي سيتم التصديق عليه في النهاية.

مراجعة التاريخ

مراجعة التاريخ