요약

  • ACSP 2026.4에서 제출자는 한 NET에서 다른 조직(Org)으로 상세 재할당(Detailed Reassignment)을 수행한 뒤, 상위 부모의 API 키가 자식 NET을 DELETE할 수 있고 정확한 시작·종료 주소를 사용해mostSpecificNet으로 조회할 수는 있지만 핸들로 동일한 자식 NET을 GET할 수는 없다고 보고했습니다. 그 경로에서는 수신 조직의 키만 성공한 것으로 보고되었습니다.
  • ARIN은 다른 조회 방법과 향후 개발 계획을 검토한 뒤 2026년 3월 30일 이 제안을 종결 처리하며, 그 시점에는 권한 변경이 불필요하다고 밝혔습니다. 이 응답은 보고된 모든 단계를 독립적으로 확인해 주지 않으며, “Closed”는 배포 증명서가 아닙니다.
  • 현재 문서는 공개 Whois/RDAP 검색, 인증된 NET Payload 작업, 수신자의 관리 권한, 직접 등록자의 회수(reclaim) 권한을 서로 구분합니다. 이러한 구분은 경로 의존적 권한에 최소 권한(principle of least privilege)이라는 강력한 방어 논거를 제공합니다.
  • 아직 풀리지 않은 운영상의 질문은 더 좁습니다: 승인된 DELETE 또는 회수에 앞서, 자동화가 사private 필드나 일반 PUT 권한을 부여받지 않고도 정확한 객체에 대한 안정적인 식별자, 의존성 미리보기, 버전 사전조건을 얻을 수 있는가?

접근 제어 표에서 가장 중요한 줄은 흔히 “허용”이나 “거부”가 아닙니다. 판단 왼쪽에 놓인 식별자입니다.

ARIN의ACSP 제안 2026.4는 한 NET에서 다른 조직으로 생성된 상세 재할당을 다룹니다. 제출자에 따르면, 직접 등록자의 API 키는 새 자식 NET을 핸들로 GET하려다 거부되었고, 수신 조직의 키는 그렇게 할 수 있었습니다. 그러나 제출자는 부모가 자식을 DELETE할 수 있고, 정확한 시작·종료 주소를 주면mostSpecificNet으로 조회할 수 있으며, Whois에서 핸들이나 IP 주소로 공개 등록 정보를 찾을 수 있다고 말했습니다.

제출자는 이 결과들을 불일치로 간주했고, 삭제 후 재생성이 비슷한 결과를 낼 수 있으므로 부모 측 PUT도 요구했습니다. ARIN은 이 논리를 받아들이지 않았습니다. 3월 30일 응답에서 ARIN은 직원들이 기존 도구를 통해 이용 가능한 다른 조회 방법과 향후 개발 계획을 논의했으며, 그 시점에 API 권한 검사를 변경할 필요는 없다고 결론지었다고 밝혔습니다. 기록은 제출자의 동의와 함께 Closed로 표시되어 있습니다.

이것이 증거 전체의 모습입니다. 보고된 동작에 대한 공식 기록이자 공식 종결 응답입니다. 취약점 공지도, 인시던트 보고도, 독립적인 재현도 아닙니다. 모든 현재 계정, 자식 NET 또는 인증 맥락이 같은 방식으로 동작한다는 것을 확립하지 않습니다. ARIN의 현재 문서는 이용 가능한 방법과 페이로드를 설명하지만, 그것 자체로 제안 속 권한 판단을 재현해 주지는 않습니다.

이 사례의 가치는 다른 곳에 있습니다. 행위자, 관계, 객체 클래스, 식별자 경로, 반환 필드 집합이 하나의 동사로 압축되면 레지스트리 권한이 얼마나 빨리 모호해지는지를 드러낸다는 점입니다.

회수는 일반 관리가 아닙니다

ARIN 경계의 가장 강한 정당성은 엔드포인트가 아니라 제도적 관계에서 시작합니다.

ARIN의자원 관리 안내는 단순 재할당(simple reassignment), 상세 재할당(detailed reassignment), 실할당(reallocation)을 구분합니다. 단순 수신자에게는 직접 관리 기능이 없습니다. 상세 재할당은 직접 관리 권한을 얻는 조직으로 향합니다. 그럼에도 직접 등록자는 회수 권한을 유지하며, 일부 역방향 DNS와 IRR 기능은 공유될 수 있습니다. 실할당은 수신자가 다시 실할당하거나 재할당할 수 있으므로 또 다른 하위 권한 구조를 만듭니다.

이는 미적 라벨이 아닙니다. 하나의 주소 블록을 둘러싼 두 조직에 서로 다른 책임을 부여합니다. 수신자는 자신의 등록과 운영 연락처를 유지할 만큼의 통제권이 필요합니다. 직접 등록자는 관계를 끝내고 자신이 여전히 책임지는 공간을 회수할 수 있는 한정된 방법이 필요합니다. 부모에게 수신자가 보유한 모든 읽기·쓰기 기능을 주면 상세 재할당이 만들려는 구분이 사라집니다.

공개/비공개 경계가 또 하나의 신중한 이유를 더합니다. ARIN은 Whois-RWS와 RDAP을 레지스트리 데이터에 기반한 공개 디렉터리 서비스로 설명합니다. 공개 응답은 핸들, 범위, 등록 사실을 보여줄 수 있지만, 반드시 인증된 프로비저닝 페이로드와 동일한 필드나 의미를 노출하지는 않습니다. 문서화된NET Payload에는 버전 데이터, 코멘트, 날짜, 수신자 식별 정보, 부모 핸들, 네트워크 이름, origin AS 값, POC 링크가 포함될 수 있습니다. 일부 계층 구조 필드는 수정 중에 변경할 수 없습니다. 핸들이 Whois에 나타난다고 해서 모든 행위자가 그 뒤의 완전한 운영 페이로드를 받아야 한다고 추론하는 것은 실수입니다.

따라서 최소 권한은 설계상 비대칭 결과를 낼 수 있습니다. 부모는 권한 부여를 철회할 수 있지만 수신자의 일반 세부 사항을 관리하지는 못합니다. 수신자는 그 관리 역할을 지므로 자식을 조회·수정할 수 있습니다. 공개 디렉터리은 더 좁은 질문에 누구나 답할 수 있습니다. DELETE가 GET을 지배하거나 GET이 PUT을 함의해야 하는 보편적인 접근 제어 법칙은 존재하지 않습니다.

이 방어는 실질적입니다. 그러나 자동화 관점에서는 불완전합니다.

같은 NET이 같은 요청은 아닙니다

현재Reg-RWS 메서드 문서는 네 가지 관련 호출을 설명합니다:

경로와 작업문서화된 출력 또는 입력운영상의 질문
GET /rest/net/NETHANDLENET Payload 반환이 행위자가 이 객체를 안정적 핸들로 조회할 수 있는가?
GET /rest/net/mostSpecificNet/STARTIP/ENDIPNET Payload 반환이 정확한 경계 범위에 해당하는 가장 구체적인 객체는 무엇인가?
DELETE /rest/net/NETHANDLETicketed Request Payload 반환이 행위자가 이 재할당 또는 실할당을 제거할 수 있는가?
PUT /rest/net/NETHANDLENET Payload 수용 및 반환이 행위자가 이 객체의 허용된 필드를 변경할 수 있는가?

이 호출들은 네 개의 동사를 표기하는 것 이상을 합니다. 각 동사를 하나의 해석 경로와 페이로드에 묶습니다. 이 결합이 중요한 이유는, 핸들은 안정적인 레지스트리 식별자인 반면 시작·종료 범위는 호출자가 이미 알고 있어야 하는 속성이기 때문입니다. 공개 Whois는 세 번째 표면으로, 인증된 프로비저닝이 아니라 디렉터리 조회에 최적화되어 있습니다.

ARIN의 더 오래된ACSP 제안 2023.13은 검색 한계를 명시합니다. 정확한 범위의mostSpecificNet호출은 임의의 포함 IP 주소에서 출발하는 일반적인 부트스트랩 방법이 아니며, 호출자는 올바른 시작과 끝을 알아야 합니다. 기술적으로 가능한 대안 경로가 운영상으로는 순환할 수 있습니다. 인벤토리가 이미 정확할 때는 도움이 되지만, 낡은 인벤토리를 반드시 고쳐 주지는 않습니다.

그래서 “다른 방법으로 조회할 수 있다”는 분석의 끝이 아닙니다. ARIN Online을 쓰는 사람에게는 검색과 확인 화면이면 충분할 수 있습니다. 자동화된 회수 절차에서는 운영자가 어느 식별자가 권위 있는지, 선택 이후 객체가 바뀌었는지, 무엇이 영향을 받는지 알아야 합니다. 유일하게 성공하는 API 조회가 로컬에 이미 저장된 정확한 범위를 요구한다면, 자동화는 레지스트리의 현재 식별자가 아니라 자신의 오래된 믿음을 확인하고 있을 수 있습니다.

DELETE 메서드는 판돈을 높입니다. ARIN은 삭제가 재할당과 실할당에만 적용된다고 설명합니다. 대상에 자식 NET이 없으면 요청이 자동으로 처리될 수 있고 삭제된 네트워크의 세부 사항을 담은 Ticketed Request Payload를 반환합니다. 중첩된 네트워크가 있으면 결과는 티켓이며, 운영자는 공간을 재발행하기 전에 성공적인 처리를 기다려야 합니다. ARIN의재할당 안내역시 사용자에게 네트워크를 찾고, Net Handle을 선택하고, 돌이킬 수 없다고 설명되는 작업을 확인하라고 지시합니다.

시스템은 재사용에 앞서 NET 식별자와 의존성 상태가 중요하다는 점을 분명히 이해하고 있습니다. 그러나 문서는 가장 풍부한 결과를 파괴적 요청 이후에 제시합니다. 바로 그 지점에서 최소 권한 사전 점검(preflight)이 유용해집니다.

권한에는 여덟 개의 좌표가 필요합니다

레지스트리 자동화 계약을 동사와 객체 이름의 2차원 표로 줄여서는 안 됩니다. 관련 단위는 다음과 같습니다:

행위자 역할 × 관계 × 객체 클래스 × 식별자 경로 × 동사 × 필드 집합 × 사전조건 × 결과

이 사례에서 “부모가 NET을 DELETE할 수 있다”는 표현은 거의 모든 안전 질문에 답하지 못합니다. 행위자가 직접 등록자인가, 자원 POC인가, 위임된 기술 연락처인가, 조직 관리자인가? 객체가 단순 재할당, 상세 재할당, 실할당 중 무엇인가? 직접 자식인가 더 깊은 후손인가? 핸들, 정확한 범위, 검색 결과 중 무엇으로 해석되었는가? 행위자는 완전한 NET Payload를 받는가, 공개 필드만 받는가, 가려진 보기를 받는가? 삭제에 현재 버전 토큰이 필요한가? 중첩 네트워크, DNS 위임, IRR 객체, POC 연관이 범위 안인가? 결과가 즉시인가 티켓인가?

같은 정밀함이 수신자도 보호합니다. 부모 측이 삭제 미리보기를 보는 기능이 코멘트, 비공개 연락처, 수신자만 관리할 수 있는 필드까지 포함할 필요는 없습니다. 권한은 작용과 공개 양면에서 모두 좁을 수 있습니다.

NET Modify 안내는 변경 전에 GET으로 현재 NET을 얻으라고 하며 올바른 원칙을 가리킵니다. 익숙한 동시성 규칙입니다: 낡은 객체를 레지스트리에 돌려보내지 마십시오. 그러나 승인된 회수 행위자가 작업에 쓰일 핸들로 객체를 조회할 수 없다면, 시스템은 다른 어떤 현재 상태 원시(primitive)도 필요로 합니다. 그렇지 않으면 안전 지침과 권한 경계가 만나지 않습니다.

이것이 현재 API가 안전하지 않다는 증명은 아닙니다. 제안 기록에는 잘못된 삭제도, 장애도, 공개된 비공개 기록도 없습니다. 검증 가능한 답을 마땅히 받아야 할 계약상 질문을 보여줄 뿐입니다.

가장 작고 유용한 해법은 삭제 미리보기입니다

ARIN이 부모에게 핸들 기준의 완전한 NET Payload나 일반 PUT 권한을 줄 필요는 없습니다. 한정된 엔드포인트가 승인된 결과적 행위를 수행하는 데 필요한 질문에만 답할 수 있습니다.

삭제 또는 회수 미리보기는 다음을 반환할 수 있습니다:

  1. 안정적인 NET 핸들과 정규화된 주소 범위;
  2. 객체 클래스와 직접 부모 관계;
  3. 비공개 연락처 필드 없이 표현된 수신자 유형;
  4. 자식 NET 존재 여부와 처리가 자동인지 티켓인지 여부;
  5. 처리가 중요한 종속 DNS, IRR, 라우팅 객체에 대한 집계 지표;
  6. 제거, 유지, 별도 조치가 필요한 기록의 범위;
  7. 현재 버전 또는 수명이 짧은 사전조건 토큰;
  8. 성공적인 실행이 생성할 알림과 감사 증거.

이후 DELETE는 그 토큰을 제시합니다. 범위, 자식 구조, 중요한 의존성 상태가 바뀌었다면 요청은 fail-closed로 실패하고 새로운 미리보기를 요구합니다. 운영자는 수신자 측 관리가 아니라 관측 가능성을 얻습니다. ARIN은 접근 경계를 유지하면서 돌이킬 수 없는 행위를 행위자가 실제 검토한 상태에 묶을 수 있습니다.

이 원시 기능 옆에 버전이 있는 공개 기능 매트릭스가 놓여야 합니다. 지원되는 각 행위자와 NET 관계, 수용되는 식별자 경로, 출력 클래스, 허용되는 동사, 불변 필드, 사전조건, 티켓 동작, 안전한 오류 경로를 열거해야 합니다. 어느 칸이 의도적으로 비대칭인지, 왜 그런지 명시해야 합니다. 동작이 바뀌면 매트릭스는 이전 버전과 효력 발생일을 보존해야 합니다.

그 문서는 하나의 제안을 넘어 더 큰 역할을 합니다. 운영자가 레지스트리 자동화를 배포하기 전에 계약 테스트를 생성할 수 있게 해 줍니다. 테스트는 직접 등록자가 한정된 회수 미리보기를 받는지, 상세 수신자가 자신의 관리 페이로드를 받는지, 단순 고객이 관리 권한을 받지 않는지, 실할당이 자신의 하위 규칙을 따르는지 확인할 수 있습니다. 테스트는 의도된 차이를 단언하고, 모든 차이를 결함으로 취급하지 않습니다.

Closed는 워크플로 상태입니다

ACSP 기록에 따르면 ARIN은 기존 도구와 향후 계획을 고려했고 그 시점에 권한 변경이 불필요하다고 판단했습니다. 합법적인 제품 판단입니다. 대안 인터페이스가 사용 사례를 충족할 수 있고, 개발 역량은 유한합니다. 제출자도 종결에 동의했습니다.

그러나 Closed는 제안의 상태로 읽어야 하며, 새로운 권한 모델이 배포되었다는 증명도, 보고된 동작이 독립적으로 확인되었다는 증명도, 근본적인 자동화 질문이 다시는 발생할 수 없다는 증명도 아닙니다. “그 시점에”이라는 표현 자체가 유용한 경계입니다.

ARIN은 운영자가 의존하도록 의도된 계약을 공개함으로써 그 경계를 지킬 수 있습니다. 의도된 규칙이 직접 등록자는 상세 재할당을 회수할 수 있지만 핸들로 수신자의 완전한 프로비저닝 페이로드를 조회할 수 없다는 것이라면, 기능 매트릭스에 명시하십시오. 정확한 범위 조회나 ARIN Online이 지원되는 사전 점검이라면, 인벤토리 가정과 반환 필드 한계를 밝히십시오. 미래의 인터페이스가 더 안전한 객체 검색을 제공할 것이라면 버전과 마이그레이션 경로를 제시하십시오.

접근 제어는 거부가 이해 가능하고 허용이 검토 가능할 때 가장 강합니다. 부모는 상위 공간을 소유한다는 이유만으로 수신자의 식별자를 물려받아서는 안 됩니다. 수신자는 부모의 회수 책임을 안전하게 수행할 수 없도록 만들어서도 안 됩니다. 공개 디렉터리를 프로비저닝 API로 착각해서는 안 됩니다. 돌이킬 수 없는 작업이 작동 시스템이 관측할 수 없는 객체 상태에 의존해서는 안 됩니다.

이 명제들은 서로 양립 가능합니다. 그 양립을 지키는 방법은 더 넓은 키가 아니라, 더 작고 명시적인 계약입니다.