요약

  • RIPE-705로 시행된 RIPE NCC 정책 2017-02는 abuse-mailbox 속성의 연 1회 이상 검증을 의무화한다. 이는 전달 가능성에 대한 검증이며, 그 메일박스로 발송된 신고가 실제로 회신되는지 여부에 대한 검증이 아니다https://www.ripe.net/community/policies/proposals/2017-02/,https://www.ripe.net/publications/docs/ripe-705/.
  • 정책 제안 2019-04는 누락된 나머지 절반을 초안화했다. 연락처가 메일박스를 모니터링하고 조치하며 회신하는지 검증하는 것, 그리고 무응답 또는 "기만적" 메일박스에 대해 RIPE NCC로의 에스컬레이션 경로를 두는 것이었다. 검토된 공개 기록에서 그 최종 결과는 확정되지 않았으며, 행위 기반 검증 정책은 시행 중이 아니다https://www.ripe.net/community/policies/proposals/2019-04/1/.
  • 레지스트리의 유일한 구속력 있는 분쟁 절차인 Conflict Arbitration Procedure(RIPE-844)는 회원과 RIPE NCC 간의 서비스 계약 및 등록 분쟁에만 적용되며, 제3자 어뷰즈 신고자에게는 개방되어 있지 않다https://www.ripe.net/publications/docs/ripe-844/.
  • RIPE-858의 집행 사다리는 LIR 폐쇄와 자원 등록 말소로 끝나지만, 문서화된 발동 조건은 등록 유효성에 근거하며 어뷰즈 행위나 무시된 신고에는 근거하지 않는다https://www.ripe.net/publications/docs/ripe-858/.
  • RIPE NCC 자체 안내는 이 경계를 명확한 언어로 밝히고 있다: "네트워크 운영자가 회신하지 않기로 선택한다면 우리가 할 수 있는 일은 아무것도 없다"https://www.ripe.net/languages/en/abuse/.

RIPE NCC 서비스 지역의 네트워크 어뷰즈 신고는 거의 전부 문서화된 경로를 따르며, 그 문서화 자체가 핵심이다. 경로는 RIPE NCC 서비스 지역 내 주소로 역추적되는 피싱 메일, 스팸 또는 스캔 트래픽을 받은 사용자에서 시작한다. 그리고 이것은 수사적 표현이 아니라 구조적 서술이지만, RIPE Database에서 역할(role) 객체의 abuse-mailbox 속성으로 기록된 이메일 주소에서 끝난다https://www.ripe.net/manage-ips-and-asns/resource-management/abuse-c-information/.

신고가 그 메일박스에 도착한 뒤 무슨 일이 일어나는가는 본 기사가 해결하려 하지 않는 주제인데, 레지스트리의 공개 기록 자체도 그것을 해결하지 않기 때문이다. 대신 이 기사는 메일박스 위에 놓인 공식 절차의 지도를 그린다: 검증 의무를 만든 정책, 회원 자격을 끝낼 수 있는 집행 사다리, 이 체계에서 유일한 구속력 있는 분쟁 절차인 중재 절차, 그리고 이들을 연결하려 시도했던 커뮤니티 제안. 이 문서들을 함께 읽으면, 회원에게는 완결되고 신고자에게는 비어 있는 에스컬레이션 구조가 드러난다.

목적지, 그리고 그것을 정의하는 정책

실질적 문서는 RIPE-705, 즉 "RIPE Database에서의 어뷰즈 연락처 관리"이며, 이는 정책 제안 2017-02 "Regular abuse-c Validation"에서 비롯되었다. 이 제안은 2018년 6월 1일 승인되어 2019년 10월 10일 시행되었다https://www.ripe.net/community/policies/proposals/2017-02/. RIPE-705는 지역 내 모든 인터넷 번호 자원이 단일 abuse-mailbox 속성을 가진 역할 객체를 참조하는 abuse-c 속성을 가질 것을 요구하고, RIPE NCC가 최소 연 1회 그 메일박스를 검증하며, 관련 정책·절차에 따라 부정확하다고 판단되는 경우 후속 조치를 취하도록 한다https://www.ripe.net/publications/docs/ripe-705/.

주의 깊게 읽으면 이 문장은 목적지와 구문 검사를 정의한다. 어뷰즈 신고를 수신하고 처리할 의무는 자원 보유자에게 있다. 레지스트리의 역할은 목적지가 존재하고 메일을 수신하는지 확인하는 것이다. 제안 2017-02는 이 경계를 명시한다: RIPE NCC는 "자원 보유자의 내부 어뷰즈 처리 절차에 개입할 권한이 없다"https://www.ripe.net/community/policies/proposals/2017-02/.

같은 제안은 실제로 존재하는 집행 수단과 그 발동 조건을 문서화한다. 기존 정책은 RIPE NCC가 무응답 사유로 LIR을 폐쇄하고 독립 자원을 말소할 수 있으며, 폐쇄·말소 절차가 발동되면 3개월의 추가 이행 기간을 둔다. 또한 5년에 걸쳐 1,000건 이상의 부정확한 abuse-mailbox 속성 관련 외부 신고가 조사·해결되었으나 폐쇄 절차는 한 번도 발동되지 않았다는 사실을 기록한다https://www.ripe.net/community/policies/proposals/2017-02/. 에스컬레이션 기계는 존재하며, 기록은 그것이 연락처 데이터의 정확성에 대해서는 작동했지만, 정확한 연락처에 도달한 신고의 처리 결과에 대해서는 작동한 적이 없음을 보여준다.

숫자로 보는 검증 기계

연간 검증의 작동 방식은 RIPE 87 Anti-Abuse Working Group 발표에 기술되어 있다. 외부 검증 도구는 형식, DNS 항목, 메일박스 존재 여부를 확인한다 — 이메일을 보내지 않고 ping으로. 부적합한 자원 객체 수준의 abuse-c는 작동하는 LIR 수준 abuse-c로 교체되며, 부적합한 LIR 수준 abuse-c는 회원 자격 종료로 이어질 수 있다. 연간 주기는 약 19,600개 LIR 조직 객체, 58,100개 LIR 자원 객체, 15,400개 독립 자원 객체를 대상으로 하며, 주당 약 2,000개 연락처를 6~8퍼센트의 실패율로 검사한다https://ripe87.ripe.net/wp-content/uploads/presentations/72-RIPE87-AAWG-final.pdf.

레지스트리의 2024년 연간 보고서는 이 작업을 수치로 제시한다: 2024년 83,509개 abuse-c 주소 검증(자동 82,658건, 수동 851건)으로 2023년 84,868건에서 감소; abuse-c 검증 조사 2,366건; abuse-c 정책 준수를 포함한 5,500건의 교정 조치를 낸 Assisted Registry Check 2,445건; 생성 또는 갱신된 abuse-c 역할 객체 102,939개로 2023년 149,228건에서 감소https://www.ripe.net/documents/4126/ripe-840.pdf.

이 수치들은 정밀하게 기록된 실제 측정이다. 측정하는 것은 문제의 첫 번째 층위다: 메일을 수신할 수 있는 메일박스. 역사적 기록은 레지스트리가 2013년 12월부터 자체 LIR이 설정하지 않은 할당 자원에 대해 abuse-c 속성을 직접 설정하기 시작했고, 2014년 초부터는 배정 자원 보유자에게 이를 요청하며 이 층위를 측정해 왔음을 보여준다https://www.ripe.net/manage-ips-and-asns/resource-management/abuse-c-information/.

행위를 검증하려 했던 제안

전달 가능한 메일박스와 작동하는 신고 처리 절차 사이의 간극은 단순히 지적된 것이 아니라 초안으로 작성된 적이 있다. 정책 제안 2019-04 "Validation of abuse-mailbox" 버전 1은 연락처가 절차와 정책을 이해하고 abuse-mailbox를 정기적으로 모니터링하며 조치를 취하고 어뷰즈 신고에 회신하는지 검증을 요구하는 것을 제안했다. 최소 6개월마다 주기적 재검증, 15일의 초기 및 에스컬레이션 기간을 제안했다. 가장 중요하게는, 에스컬레이션 경로를 초안화했다: 기만적 행위 — 예컨대 RIPE NCC의 이메일이나 특정 제목·내용의 메시지에만 회신하는 메일박스 — 또는 어뷰즈 사안에 응답하지 않는 것은 재검증을 위해 RIPE NCC에 보고될 수 있었다https://www.ripe.net/community/policies/proposals/2019-04/1/.

이것이 에스컬레이션 구조에서 가장 중대한 단일 문서다. 커뮤니티가 정확한 실패 양상 — 도달 가능하다고 검증되었지만 실제 신고에는 결코 회신하지 않는 메일박스 — 을 파악하고, 검증을 행위와 연결하는 메커니즘을 토대에 올렸음을 보여주기 때문이다. 회수된 기록이 확립하는 것은 버전 1 문안이다. 그 최종 결과 — 철회, 거부, 만료 또는 대체 어느 것이었는지 — 는 여기서 검토한 문서들로는 확정되지 않으며, 이 기사는 어느 쪽도 주장하지 않는다. 검증 가능한 것은 대조다: 현행 체계 하에서 행위 기반 검증 정책은 시행 중이 아니다. 기록상의 정책은 여전히 RIPE-705이며, 이는 회신이 아닌 속성을 검증한다https://www.ripe.net/publications/docs/ripe-705/.

레지스트리가 조사하지 않는 것

이 경계는 신고 절차 페이지에도 명시되어 있다. RIPE NCC 네트워크 외부에서 발생한 스팸, 피싱 및 기타 네트워크 어뷰즈 신고는 "레지스트리로서의 RIPE NCC 책임 범위에 속하지 않으므로 조사 대상으로 고려되지 않는다." 회원 간 분쟁, 또는 RIPE NCC 자체와의 분쟁은 Arbiters Panel로 안내된다https://www.ripe.net/about-us/support/contact/reporting-procedure/.

어뷰즈 신고자를 위한 RIPE Labs 안내는 신고자의 관점에서 같은 한계를 진술한다: RIPE NCC에는 "분쟁에 개입하거나 신고를 제출함으로써 제3자를 대신해 행동할 직접적 권한이 없다." 어뷰즈 연락처가 응답하지 않으면 자원의 관리(administrative) 또는 기술(technical) 연락처에 접촉할 것을 제안하고, 심각한 어뷰즈 피해자는 사법기관으로 안내한다https://labs.ripe.net/author/angela_dallara/ripe-ncc-anti-abuse-support-what-to-do-if-it-happens-to-you/.

레지스트리 자체의 어뷰즈 정보 페이지는 이 문서군 중 가장 노골적인 문서다: "우리의 역할은 RIPE Database의 모든 어뷰즈 연락처가 유효하고 최신 상태인지 확인하는 것이다. 이후 어뷰즈 신고의 처리는 네트워크 운영자의 책임이다. 네트워크 운영자가 회신하지 않기로 선택한다면 우리가 할 수 있는 일은 아무것도 없다"https://www.ripe.net/languages/en/abuse/.

유일한 구속력 있는 절차, 그리고 배제되는 사람

Conflict Arbitration Procedure(RIPE-844)는 이 체계에서 유일한 구속력 있는 에스컬레이션 절차이며, 그 적용 범위가 결정적 사실이다. 중재는 표준 서비스 계약과 관련하여 이사회 또는 경영진의 결정 — 절차 및 RIPE 정책의 이행을 포함 — 에 대해 회원과 RIPE NCC 사이의 분쟁, 그리고 자원 등록에 관한 회원 간 분쟁을 다룬다. 양 당사자는 먼저 쌍무적 해결을 시도하고 문서화해야 하며, 그다음에야 어느 쪽이든 중재를 요청할 수 있다. 판정은 집행 가능하고 강제력이 있어야 하며 12주(연장 가능) 내에 결정된다. 한 당사자가 판정에 따르지 않고 2주 내 관할 법원에 분쟁을 제출하지 않으면 RIPE NCC는 그 당사자와의 표준 서비스 계약을 종료할 수 있다. 절차 비용은 패소한 쪽이 부담하며 5,000유로 미만이어야 한다https://www.ripe.net/publications/docs/ripe-844/.

이 절차의 모든 요소는 회원 자격을 전제한다. 제3자 어뷰즈 신고자 — 피싱 피해자, 스팸 출처 상류의 네트워크 관리자, 보안 연구자 — 는 표준 서비스 계약의 당사자가 아니며, 쌍무적 해결을 요구할 수도, 중재를 요청할 수도, 어떤 판정의 수혜자가 될 수도 없다. 이 구조에서 유일한 구속력 있는 절차는 신고자의 위치에서 구조적으로 도달 불가능하다.

종료 사다리, 그리고 무엇이 발동시키는가

RIPE-858 "회원 폐쇄, 인터넷 자원 및 레거시 인터넷 자원의 등록 말소"는 최종 제재를 작동화한다. 문서화된 발동 조건은 등록 유효성이다: inetnum, inet6num 또는 aut-num 객체에서 참조되는 무효한 abuse-mailbox는 부정확한 등록으로 간주될 수 있고, 부정확하거나 모호한 등록에 관한 특정 RIPE NCC 요청에 반응하지 않으면 다른 곳에서 응답적이더라도 무응답으로 간주된다. 30일, 60일, 90일 단계의 리마인더가 관리이사의 종료 통지에 앞선다. 중재인 판정 미이행은 별개의 종료 사유다https://www.ripe.net/publications/docs/ripe-858/.

이 사다리는 실제로 존재하고, 가파르며, 문서화된 설계상 레지스트리 데이터베이스에 키가 걸려 있다. 등록된 메일박스가 RIPE NCC의 검증 ping은 수용하지만 그것으로 발송된 모든 피싱 신고를 무시하는 운영자는 이 사다리의 어떤 문서화된 발동 조건도 위반하지 않는다. 집행 구조는 등록 데이터로 회원 자격을 종료할 수 있지만, 공개 기록상 제3자 신고의 처리 결과로는 발동될 수 없다.

기록 자체가 보존하는 역사

이것이 처음부터 설계였음은 레지스트리의 오래된 계획 문서에서도 드러난다. RIPE-662, 즉 2016년 활동 계획 및 예산에는 "인터넷 번호 자원 조사, 분쟁 및 하이재킹 처리"라는 제목의 Registry Maintenance 하위 항목이 담겨 있는데, 2012년 이후 조사된 잠재적 하이재킹 252건, 2014년 7월 1일부터 2015년 6월 30일까지의 조사 85건, 같은 기간 조사된 어뷰즈 신고 572건을 언급하는 것으로 알려져 있다. 이 수치는 PDF 문서 자체의 직접 확인이 아니라 메일링 리스트에서의 PDF 인용을 통해서만 회수된 기록에 입증되므로, 그러한 단서와 함께 읽어야 한다https://www.ripe.net/publications/docs/ripe-662/,https://www.ripe.net/ripe/mail/archives/anti-abuse-wg/2016-August/003548.html. 주목할 점은 범주적 성격이다. 레지스트리가 집계한 조사는 하이재킹, 자원 분쟁 등 등록 사실에 관한 레지스트리 자체의 조사였지, 회원의 어뷰즈 처리가 어떻게 수행되는가에 대한 측정이 아니었다.

이 구조가 종합되는 것

문서들을 종합하면 정확한 형태를 지닌 시스템이 드러난다. 목적지는 정의되어 연간 검증되며, 집계치가 공개된다https://www.ripe.net/publications/docs/ripe-705/,https://www.ripe.net/documents/4126/ripe-840.pdf. 집행 사다리는 정의되어 등록 데이터에 키가 걸려 있다https://www.ripe.net/publications/docs/ripe-858/. 구속력 있는 분쟁 절차는 정의되어 회원 자격에 키가 걸려 있다https://www.ripe.net/publications/docs/ripe-844/. 레지스트리의 권한 없음 선언은 정책 제안, 신고 절차, 공개 안내 세 곳에서 각각 진술된다https://www.ripe.net/community/policies/proposals/2017-02/,https://www.ripe.net/about-us/support/contact/reporting-procedure/,https://www.ripe.net/languages/en/abuse/. 그리고 행위를 검증했을 유일하게 초안화된 메커니즘인 2019-04는 결과가 확정되지 않은 제안으로 기록에 존재하며, 행위 검증 정책은 시행 중이 아니다https://www.ripe.net/community/policies/proposals/2019-04/1/.

선행 보도들은 검증 캠페인의 집계치와 주기, 응답 품질에 대한 4층 프레임워크, 그리고 어뷰즈 연락처를 생성·유지하는 관리자 사슬을 다루었다https://btw.media/en/ripe-abuse-c-validation-compliance-not-accountability,https://btw.media/en/ripe-abuse-named-custodian,https://btw.media/en/governance/rir-watchdog/ripe-ncc/story/ripe-abuse-accountability-and-the-limits-of-registry-recourse. 본 기사는 그 보도들이 끝난 곳에서 한 단계 더 나아가 에스컬레이션 층위를 추가한다: 공식 절차 그 자체와 그것을 규정하는 비대칭. 구조의 모든 문서화된 발동 조건은 레지스트리가 회원에 대해 검증할 수 있는 것 — 전달 가능한 메일박스, 정확한 등록 데이터, 판정 또는 서비스 계약 준수 — 에 근거한다. 구조 어디에도, 도착한 신고를 회원이 어떻게 처리하는가에 근거하는 조건은 없다. 회원은 완전한 준수와 전면적인 무응답의 교차점에 놓일 수 있고, 문서화된 그대로 이 구조에는 그 위치에 대응하는 어떤 지렛대도 없다.

신고자에게 실질적 결과는 이 모든 문서화에 의해 변하지 않는데, 바로 그것이 결론이다: "신고하면 그 다음은?"이라는 질문에 대한 문서화된 답은, 시스템이 문을 검증하지만 그 문에 누가 응답하는지에는 공식적으로 무관심하며, 그렇다고 명시한다는 것이다.