التفاصيل
تحديث سياسة إساءة الاتصال |
|||
هوية شخصية: |
افبوب-2018-GEN-001-DRAFT03 |
تاريخ التقديم: 5 يونيو 2019 الاسم: 3.0 تعديل: CPM art 8.0 |
|
كاتب: |
جوردي باليت مارتينيز jordi.palet فيipv6company.com منظمة IPv6 الشركة
|
||
المتقادمون: |
|
مقترح
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 من الاجتماع التحضيري للمؤتمر ، على النحو التالي:
الحالي |
المقترح |
8.1 مقدمة تحدد هذه السياسة كائنًا مخصصًا يجب استخدامه كمكان مفضل لنشر معلومات الاتصال العامة عن إساءة الاستخدام داخل منطقة خدمة AFRINIC. يمكن الإشارة إلى الكائن المذكور في كائنات inetnum و inet6num و aut-num في AFRINIC whois قاعدة البيانات. يوفر طريقة أكثر دقة وفعالية لتقارير إساءة الاستخدام للوصول إلى جهة اتصال الشبكة الصحيحة |
8.1 مقدمة تحدد هذه السياسة كائنًا إلزاميًا يجب استخدامه لنشر إساءة استخدام معلومات الاتصال العامة داخل منطقة خدمة AFRINIC. يجب الإشارة إلى الكائن المذكور في كائنات inetnum و inet6num و aut-num في AFRINIC whois قاعدة البيانات. يوفر طريقة أكثر دقة وفعالية لتقارير الإساءة للوصول إلى جهة الاتصال الصحيحة. |
8.2 تفاصيل السياسة: لإتاحة ملف جديد أو استخدام ملف whois كائن قاعدة البيانات الذي يقوم بتنفيذ الخصائص التالية:
يجب أن يكون الكائن يمكن الوصول إليه من خلال whois بروتوكول. AFRINIC لنشر أ أفضل ورقة الممارسة يشجع جميع الأعضاء على استخدام الكائن بنشاط لنشر معلومات الاتصال التي تسيء الاستخدام. |
8.2 وصف "abuse-c" و "abuse-mailbox" يجب أن تتضمن الموارد التي خصصتها / عينتها AfriNIC سمة اتصال إلزامية "abuse-c" (جهة اتصال تعاطي) في المطابقة الخاصة بها WHOIS إدخال ، مع واحد على الأقل من صندوق الوارد للبريد الإلكتروني (البريد - سوء الاستخدام) صالح ومراقب ومدار بشكل فعال والمقصود لتلقي التقارير اليدوية أو التلقائية فيما يتعلق بالسلوك التعسفي ومشكلات الأمان وما شابه. يجب أن تكون السمة "abuse-mailbox" متاحة بطريقة غير مقيدة عبر whois، واجهات برمجة التطبيقات والتقنيات المستقبلية. بالنظر إلى الطبيعة الهرمية لعناصر عنوان IP ، قد تتم تغطية الكائنات التابعة لتلك التي توزعها AfriNIC مباشرة بواسطة الكائنات الأصلية أو قد يكون لها سمة "abuse-c" الخاصة بها. باتباع الممارسات المعتادة ، قد يتم تضمين سمات "البريد الإلكتروني" الأخرى لأغراض أخرى. |
8.3 مزايا وعيوب السياسة 8.3.1 المزايا
8.3.2 العيوب سيواجه هذا الكائن ، مثل جميع الكائنات الموجودة الأخرى ، مشكلة دقة البيانات. تهدف هذه السياسة إلى معالجة مشكلة المكان المفقود لمعلومات الاتصال الخاصة بإساءة الاستخدام ولن تؤدي إلى تحسين دقة البيانات في whois قاعدة البيانات. ومع ذلك ، يُقترح على AFRINIC تقديم طريقة لتلقي التقارير حول عدم العمل أو عدم دقة الأشياء. |
8.3 حول "صندوق بريد إساءة الاستخدام" يجب أن تتطلب رسائل البريد الإلكتروني المرسلة إلى "صندوق البريد - سوء الاستخدام" التدخل اليدوي من قبل المستلم في مرحلة ما ، وقد لا تتم تصفيتها ، لأن هذا قد يمنع في بعض الحالات تلقي تقارير إساءة الاستخدام. على سبيل المثال ، في حالة البريد العشوائي ، حيث يمكن أن يتضمن تقرير إساءة الاستخدام رسالة البريد العشوائي نفسها أو عناوين URL أو المحتوى الذي يصنف عادةً على أنه بريد مزعج. قد يقوم "صندوق البريد - سوء الاستخدام" في البداية بإرسال رد تلقائي ، على سبيل المثال ، تعيين رقم بطاقة ، وتطبيق إجراءات التصنيف ، وطلب مزيد من المعلومات ، وما إلى ذلك. ومع ذلك ، لا ينبغي أن يطلب من مراسل إساءة الاستخدام تعبئة نموذج ، لأن هذا يعني ضمناً أن ستضطر كل شركة تحتاج إلى الإبلاغ عن حالات إساءة الاستخدام (وهي مهمة يتم تشغيلها تلقائيًا في العادة) إلى تطوير واجهة محددة لكل مزود خدمة إنترنت في العالم يفرض تعبئة النماذج ، وهو أمر غير ممكن أو منطقي ، حيث إنه سيضع تكلفة معالجة الإيذاء على من يقدمون الدعوى ومن ثم يقعون ضحايا سوء المعاملة ، بدلاً من أن يدفعوا من قبل أولئك الذين يتسبب موكلهم في سوء المعاملة (ومن يحصلون على دخل منهم). عن طريق المعلومات ، تجدر الإشارة إلى أنه من المعقول توقع أن يرسل إجراء الإبلاغ عن إساءة الاستخدام ، مع تقرير الاعتداء الأولي ، السجلات ، نسخة من رسالة البريد العشوائي (إرفاق مثال على البريد الإلكتروني العشوائي أو رؤوسه الكاملة) أو أدلة معادلة (حسب نوع الإساءة). وبالمثل ، من المعقول توقع أن تحدد رسالة البريد الإلكتروني الأولية للرد التلقائي أن المطالبة لن تتم معالجتها ما لم يتم تقديم مثل هذه الأدلة ، مما يتيح للمرسل فرصة لتكرار عملية التقديم وإدراج الأدلة ذات الصلة. يسمح ذلك بالإبلاغ التلقائي ، على سبيل المثال ، عبر fail2ban أو SpamCop أو غيرهم ، مع الحفاظ على التكاليف كحد أدنى لكلا الطرفين المعنيين. بشكل عام ، إذا تم إنشاء رقم تذكرة ، فيجب الاحتفاظ به (عادةً كجزء من الموضوع) من خلال الاتصالات المتتالية. |
8.4 أهداف التحقق من صحة "abuse-c" / "abuse-mailbox" يجب أن يحقق الإجراء ، الذي سيتم تطويره بواسطة AFRINIC ، الأهداف التالية:
قد يتم تعديل فترات التحقق "الأولية" و "التصعيدية" من قبل AFRINIC ، عند الاقتضاء ، لإبلاغ المجتمع بالدوافع. على سبيل المثال ، قد يستغرق الأمر وقتًا أطول للتحقق من الصحة ، بمجرد تنفيذ هذه السياسة ، وتقصيرها بعد ذلك بمجرد انخفاض نسبة حالات الفشل ، وبالتالي تزيد جودة جهات الاتصال وبالتالي يمكن توقع انخفاض متوسط أوقات الاستجابة لسوء المعاملة. (على سبيل المثال ، يتم تضمين إجراء مفصل في اقتراح السياسة هذا ضمن "معلومات إضافية"). |
|
8.5 التحقق من صحة "abuse-c" / "abuse-mail" ستقوم AFRINIC بالتحقق من الامتثال للعناصر المذكورة أعلاه ، سواء عند إنشاء أو تحديث سمات "abuse-c" و / أو "abuse-mailbox" ، وكذلك بشكل دوري ، لا تقل عن مرة واحدة كل 6 أشهر ، وكلما رأت AFRINIC مناسبة. سيؤدي عدم الامتثال إلى متابعة أكثر شمولاً وتحذيرات ومنع خدمات معينة وفقًا لتقدير AFRINIC وفقًا للسياسات / الإجراءات ذات الصلة. يمكن تعديل وتيرة التحقق الدوري إذا رأت AFRINIC هذا مناسبًا وأبلغت المجتمع بأسبابه. على سبيل المثال ، يمكن إجراء التحقق من الصحة واحدًا في السنة الأولى ، لتسهيل الالتزام بالسياسة ، ومن ثم يمكن أن يزيد عدد عمليات التحقق السنوية بشكل تدريجي ، حتى تصل إلى الفصلية ، بهدف تحسين جودة جهات الاتصال. |
|
8.6 التصعيد إلى AFRINIC من أجل السماح بتصعيد السلوك الاحتيالي (على سبيل المثال ، "صندوق بريد لإساءة الاستخدام" لا يرد إلا على رسائل البريد الإلكتروني الخاصة بشركة AFRINIC ، أو على رسائل ذات موضوع أو محتوى محدد) ، أو عدم الامتثال للجوانب المتبقية من هذه السياسة (غير صحيحة أو عدم الاستجابة لحالات الإساءة) ، ينبغي توفير طريقة تصعيد ، مما يسمح بإعادة التحقق من الصحة (وفقًا للمادة 8.5 أعلاه). |
3.2 معلومات إضافية:
نظرًا لتنفيذ هذا الاقتراح ، ستنشر AFRINIC IRT كاسم مستعار إلى abuse-c ، من أجل تسهيل البحث في whois للحصول على نفس المعلومات ، بغض النظر عما إذا كنت تبحث عن abuse-c أو IRT. يمكن الاحتفاظ ببقية المعلومات الفعلية الموجودة في IRT وفقًا للإرشادات الفعلية (التي ستحتاج إلى تحديث AFRINIC). يتم ذلك من أجل استيعاب IRT في غالبية RIRليالي حيث هو سوء المعاملة ج.
مثال على إجراء التحقق من الصحة.
- تبدأ AFRINIC عملية التحقق من الصحة تلقائيًا ، حيث ترسل اثنان من رسائل البريد الإلكتروني المتتالية إلى "علبة البريد الخاصة بالإساءة".
- سيتم إرسال رسائل البريد الإلكتروني هذه تحتوي على نص عادي فقط.
- وفقًا لتقدير AFRINIC ، بشكل عام أو في حالات محددة (على سبيل المثال ، للتأكيد في حالات التصعيد أقل من 8.6) ، يجوز لـ AFRINIC استخدام مجالات أخرى بخلاف afrinic. * ، وحتى تعديل موضوع ونص الرسالة. أداء التحقق من صحة وقال أكثر فعالية.
- ستتضمن رسالة البريد الإلكتروني الأولى عنوان URL الذي يجب إجراء التحقق منه ("validacion.afrinic.net") وقد تحتوي على معلومات حول الإجراء ، وموجز موجز لهذه السياسة ، إلخ.
- سوف يحتوي البريد الإلكتروني الثاني على رمز تحقق أبجدي رقمي فريد.
- يجب على الشخص المسؤول عن "علبة البريد الخاصة بإساءة الاستخدام" الانتقال إلى عنوان URL ولصق الرمز الذي تم استلامه في البريد الإلكتروني الثاني في النموذج.
- يجب تصميم عنوان URL بطريقة تمنع استخدام عملية تلقائية (على سبيل المثال ، "captcha"). بالإضافة إلى ذلك ، يجب أن يحتوي على نص يؤكد أن الشخص الذي يقوم بالتحقق من الصحة يفهم الإجراء والسياسة ، وأنهم يراقبون بانتظام "صندوق البريد الخاص بالإساءة" ، واتخاذ التدابير اللازمة لحل حالات إساءة الاستخدام المبلغ عنها ، وأن تقرير إساءة الاستخدام يتلقى ردًا ، مع "مربع اختيار" يجب قبوله للمتابعة.
- سيكون الرمز الأبجدي الرقمي صالحًا لمدة أقصاها 15 يوم عمل.
- إذا لم يتم إدخال الرمز في غضون ذلك الوقت ، فسيقوم النظام بوضع علامة "abuse-c" على أنه "غير صالح مؤقتًا" وسوف ينبه موظفي AFRINIC حتى يتمكنوا من بدء متابعة مخصصة مع صاحب المورد.
- إذا لم يتم تلقي أي رد يؤكد أن الموقف قد تم تصحيحه ، بعد فترة إضافية من 15 يوم عمل ، سيتم وضع علامة "abuse-c" بشكل دائم على أنها "غير صالحة".
- يجب على AFRINIC التأكد من وضع جميع وسائل "تحذير" صاحب المورد في مكانها الصحيح ، مثل رسائل البريد الإلكتروني الدورية إلى صناديق البريد الإلكتروني الأخرى ، والنوافذ المنبثقة في حالة تأهب ، إلخ. يجب أن تحتوي جميع هذه على نص السياسة والتذكيرات بشأن العواقب في حالة استمرار انتهاك السياسة. وينبغي أيضا النظر في وسائل منع الوصول إلى بعض الخدمات.
- سيتم تكرار عملية التحقق من الصحة تلقائيًا (البنود من 1 إلى 8 أعلاه). إذا كان مرضًا ، فسيتم تمييز "abuse-c" على أنه "صالح" ؛ وإلا سيتم النظر في انتهاك للسياسة.
- يجب أن يكون هناك أدوات مثل نموذج ، صندوق بريد (على سبيل المثال ، صندوق بريد مثل "محمي عنوان البريد الإلكتروني هذا من المتطفلين و برامج التطفل. تحتاج إلى تفعيل جافا سكريبت لتتمكن من مشاهدته.") ، أو غيرها في المستقبل ، لتصعيد عدم الامتثال لهذه السياسة وحتى للوساطة من قبل AFRINIC ، وعند الاقتضاء ، وتطبيق السياسات / الإجراءات ذات الصلة ، وخاصة تلك المتعلقة بإلغاء الموارد.
مراجع حسابات
تم قبول اقتراح مماثل في APNIC وهو قيد المناقشة في مناطق ARIN و LACNIC و RIPE.
تقييم الموظفين
مقترح |
افبوب-2018-GEN-001-DRAFT03 |
العنوان |
تحديث سياسة إساءة الاستخدام - الإصدار 3 |
اقتراح UR |
https://afrinic.net/policy/proposals/2018-gen-001-d3#proposal |
تقييم |
20 يوليو 2019 |
1.0 فهم الموظفين للاقتراح
- نص سياسة الاستبدال إلى CPM 8.0 الحالي (معلومات جهة اتصال إساءة الاستخدام) - [القسم 8.1]
- يقدم سمة "abuse-c" إلزامية في inetnum و inet6num و aut-num whois كائنات قاعدة البيانات. قيمة هذه السمة هي عنوان بريد إلكتروني (صندوق بريد إساءة) ، يتم إرسال جميع المعلومات المتعلقة بإساءة الاستخدام إليه. يُعد صندوق البريد الإلكتروني المسيء اختياريًا في الكائنات التابعة للتخصيصات أو التعيينات الأصلية المباشرة الصادرة عن AFRINIC - [القسم 8.2]
- يجب أن يكون صندوق بريد إساءة الاستخدام صالحًا ويتم مراقبته بنشاط من خلال التحقق من الفترة - [القسم 8.2]
- يجب أن يحتاج البريد الإلكتروني المرسل إلى صندوق بريد إساءة الاستخدام إلى تدخل يدوي من قبل المستلم في مرحلة ما- [القسم 8.3]
- يجب على AFRINIC توفير نظام للتحقق من صحة صندوق بريد إساءة الاستخدام. تُترك العملية الفعلية لتقدير موظفي AFRINIC ، ولكن يمكن أن تتبع مثالاً للإجراء الوارد في القسم 3.2 من اقتراح السياسة ، مع الحد الأدنى الموصى به للفاصل الزمني للتحقق مرة واحدة على الأقل كل 6 أشهر - [القسم 8.4]
- ستؤدي علب البريد Abuse-c التي تفشل في اختبارات التحقق من الصحة إلى الحظر النهائي لخدمات معينة ، وفقًا لتقدير AFRINIC (ووفقًا للسياسات / الإجراءات ذات الصلة) - [القسم 8.5]
- يجب توفير آلية تصعيد إلى AFRINIC حيث يمكن الإبلاغ عن أي مخاوف تتعلق بعملية التحقق من قبل المجتمع و / أو الأعضاء. يمكن أن يساعد هذا أيضًا في عمليات إعادة التحقق اليدوية. - [القسم 8.6]
2.0 تعليقات الموظفين
- يوجد بالفعل حل موجود من خلال كائن IRT ، وهو اختياري حاليًا - (والذي يبدو أنه يعالج الغرض من الاقتراح) - والذي يمكن جعله إلزاميًا لكائنات الموارد التي تم إصدارها مباشرةً بواسطة AFRINIC. ميزة إضافية لاستخدام IRT هي أنه يمكن أن يحتوي على معلومات أكثر من مجرد عنوان بريد إلكتروني ، مثل العنوان الفعلي وأرقام الهواتف ومفاتيح PGP للاتصال الآمن.
- خلال اجتماع السياسة العامة AFRINIC30 ، أوضح المؤلف أن IRT يمكن أن يكون "اسمًا مستعارًا" لإساءة استخدام c. ومع ذلك ، نلاحظ أنه من المربك استخدام IRT كاسم مستعار لـ abuse-c والعكس صحيح - لن نعرف كيفية تنفيذ مثل هذا المطلب ما لم يوجه المؤلف بمواصفات مفصلة من خلال اقتراح السياسة أو من خلال (DBWG ) مجموعة عمل قاعدة البيانات.
- في 8.5 المقترح حيث ستؤدي علب البريد إساءة-c التي تفشل في اختبارات التحقق من الصحة إلى الحظر النهائي لخدمات معينة ، وفقًا لتقدير AFRINIC (ووفقًا للسياسات / الإجراءات ذات الصلة). يجب أن يكون اقتراح السياسة واضحًا بشأن الخدمات المحددة التي سيتم حظرها. ومع ذلك ، من المهم ملاحظة أنه بدون هذا البند في المقام الأول ، فإن خرق السياسة (مثل عدم وجود إساءة استخدام صالحة - ج إذا تم تمرير هذا الاقتراح) يرقى إلى انتهاك RSA ، والذي يمكن أن يؤدي في نهاية المطاف إلى إلغاء نفس RSA والخدمات المرتبطة بها.
3.0 ملاحظات قانونية
بدون سلوفان
- التنفيذ:
- الجدول الزمني والأثر: حوالي 6 أشهر من أعمال تطوير البرمجيات.
- متطلبات التنفيذ: تعديلات على WHOIS قاعدة البيانات بناءً على الحل الذي سيتم التصديق عليه في النهاية.
مراجعة التاريخ
مراجعة التاريخ
التاريخ |
التفاصيل |
١٣ أغسطس ٢٠٢٣ |
الإصدار 1: AFPUB-2018-GEN-001-DRAFT01 في البداية Draft تم النشر إلى rpd |
20 نوفمبر 2018 |
الإصدار 2: AFPUB-2018-GEN-001-DRAFT02 الإصدار 2 أرسلت إلى rpd |
5 يونيو 2019 |
الإصدار 3: AFPUB-2018-GEN-001-DRAFT03
|