요약

  • LACNIC의 Registration API 페이지는 운영자에게 최신 v3 문서를 위해 Postman을 사용하라고 안내하지만, 같은 페이지의 경로 표는 항목 주소 방식의serialNumber경로에서 ROA 수정과 삭제를 설명합니다.
  • 연결된 컬렉션은 그 대신 기존 ROA 목록을 교체하는 조직 범위의 PUT과, 별도의 조직 범위 폐기 경로를 문서화합니다. 확인된 공개 예시에는 해당 교체에 대한 기준 버전, 의도된 차이 또는 오래된 쓰기 조건이 나타나지 않습니다.
  • 목록 전체의 원하는 상태는 단순하고, 원자적이며, 멱등적일 수 있습니다. 버전화된 실행 가능한 계약은 이러한 장점을 유지하면서 운영자가 어느 목록을 검토했는지, 무엇을 변경하려 했는지, 서버가 그 정확한 전환을 수락했는지 증명할 수 있게 합니다.

LACNIC의Registration API 페이지에 도착한 운영자는 합리적인 안내를 받습니다. 최신 버전 3 문서는 Postman을 사용하라는 것입니다. 이는 단순한 편의 링크가 아닙니다. 다른 설명 문구가 낡았을 때 어느 공개 표면이 구현을 지배해야 하는지 독자에게 알려줍니다.

그러나 같은 페이지의 표는 ROA에 대해 다른 정신 모델을 제공합니다. 생성과 조회는/rpki/roas에 있습니다. 수정과 삭제는/rpki/roas/{serialNumber}에 있습니다. 이 항목은 개별적으로 주소 지정이 가능해 보입니다. 일련번호를 찾아 해당 레코드에 작업을 수행하고, 나머지 컬렉션은 작업 대상 밖에 두면 됩니다.

운영/lacnic/v3/info경로는 현재 동일한 공개 Postman 문서로 리디렉션합니다. 연결된 컬렉션인API Registro v3 Prod에서 조회와 생성은/lacnic/v3/rpki/roas/{organizationId}에서 조직 범위로 이루어집니다. 업데이트는 해당 경로로의 PUT이며, 설명에 따르면 기존 목록이 업데이트된 버전으로 교체됩니다. 폐기는/lacnic/v3/rpki/roas-delete/{organizationId}로 목록을 POST하는 방식입니다.

이는 URL을 쓰는 두 가지 방식 사이의 외형적 차이가 아닙니다. 의도의 단위를 바꿉니다. 웹사이트 표는 항목을 설명합니다. 컬렉션은 집합을 설명합니다.

집합 교체의 가장 좋은 근거

컬렉션 설계에는 강력한 운영적 근거가 있습니다. 클라이언트는 조직의 현재 목록을 조회하고 원하는 목록을 계산해 그 완전한 상태를 PUT할 수 있습니다. 부분 성공이 중간 설정을 남길 수 있는 생성·수정·삭제 연쇄를 조율할 필요가 없습니다. 서버는 집합 전체를 검증하고 원자적으로 커밋할 수 있습니다. 동일한 요청을 반복하면 자연히 동일한 결과로 수렴합니다.

이것이 선언적 인터페이스의 매력입니다. 클라이언트는 모든 내부 단계를 지시하는 대신 무엇이 존재해야 하는지 진술합니다. IP 주소 관리나 라우팅 보안 자동화를 통해 많은 권한을 관리하는 조직에게는 항목 단위 명령 대기열보다 하나의 일관된 원하는 상태가 검토하기 쉬울 수 있습니다.

LACNIC은 공개 예시에 드러나지 않는 방식으로 이 작업을 보호할 수도 있습니다. 조직 단위로 쓰기를 직렬화하거나, 내부 리비전을 비교하거나, 충돌을 거부하거나, 상세한 보호 이력을 보존하거나, 커밋 전에 차이를 계산하거나, 인증된 사용자에게 추가 도구를 제공할 수 있습니다. 이 연구에서는 인증된 요청이 이루어지지 않았습니다. 공개 문서는 운영 환경에 그러한 통제가 없다는 것을 입증하지 않습니다.

이 방어가 중요한 이유는, 예시에서 누락된 필드가 사고가 아니기 때문입니다. 그것은 자격 증명을 갖고 실제 상태를 시험하기 전에 구현자가 알 수 있는 범위의 한계입니다. 따라서 타당한 비판은 더 좁습니다. LACNIC 스스로 최신이라고 지목한 공개 계약은 완전한 교체가 클라이언트가 기반으로 삼은 목록에 어떻게 결속되는지 보여주지 않습니다.

전체 목록은 존재하지 않는 레코드도 결정으로 전달한다

항목 단위 업데이트는 사실상 '이 객체를 변경하라'고 말합니다. 전체 목록 교체는 더 많은 것을 말합니다. 이 페이로드의 모든 객체를 조직의 결과 집합으로 만들어라. 따라서 생략된 항목은 추가된 항목만큼 결과가 커질 수 있습니다.

서로 다른 시각에 같은 조직을 읽는 두 개의 인증된 자동화 프로세스를 상상해 보십시오. 하나는 새 프리픽스에 대한 새 ROA를 준비합니다. 다른 하나는 기존 권한의maxLength를 수정합니다. 각자 자신이 관찰한 상태를 기준으로 완전한 목록을 제출합니다. 공개 계약에 보이는 기준 버전이나 충돌 조건이 없다면, 어느 클라이언트도 문서만으로 이후 쓰기가 자신의 읽기 이후 이루어진 변경을 병합하는지, 거부하는지, 직렬화하는지, 교체하는지 알 수 없습니다.

이것은 동시성 예시이며, LACNIC이 업데이트를 잃었다는 보고가 아닙니다. 서버가 정확히 그 결과를 방지하고 있을 수 있습니다. 요점은 확인된 요청·응답 예시가 어느 규칙이 적용되는지 클라이언트에게 알려주지 않는다는 것입니다. 예시에는ETag,If-Match, 리비전 토큰, 기준 목록 해시 또는 그에 준하는 사전 조건이 없습니다. 드라이런, 미리보기 또는 의도된 차이도 없습니다. 문서화된 업데이트 응답에는 작업 결과를 대조할 수 있는 공개 예시 본문이나 응답 헤더가 없습니다.

ROA에서 이 구분이 중요한 이유는 목록이 무해한 라벨의 목록이 아니기 때문입니다. 현재RFC 9582의 ROA 프로필에 따르면 권한은 IP 주소 공간을 원점 AS에 결속시키며, 선택적 최대 길이를 둘 수 있습니다.RFC 9319는maxLength를 부주의하게 사용하면 어떤 더 구체적인 광고가 커버되는지 바꿀 수 있음을 설명합니다. 권한을 생성하거나 좁히거나 생략하는 것은 경로-원점 검증이 광고를 분류하는 근거를 바꿀 수 있습니다.

그렇다고 API가 라우터의 결정에 책임을 지는 것은 아닙니다. 의존 네트워크는 RPKI 데이터를 어떻게 가져오고 사용할지 스스로 선택합니다. 다만 레지스트리 쓰기는 그 영향에 비례하는 운영 계약을 받아야 한다는 뜻입니다. 조직이 요청이 우연히 성공했는지 여부로 동시성 모델을 추측하도록 두어서는 안 됩니다.

두 공개 표면은 하나의 실행 가능한 정의에서 나와야 한다

첫 번째 수리는 문서적입니다. 웹사이트 표,/info목적지, Postman 컬렉션은 하나의 버전화된 경로 정의의 투영이어야 합니다. 업데이트가 조직 범위의 목록 교체라면 요약 표도 그렇게 말해야 합니다. 항목 주소 경로가 계속 지원된다면 계약은 그것이 하나의 객체를 편집하는지, 집합 작업으로 변환되는지, 오래된 호환성 표면에 속하는지 설명해야 합니다.

Postman 공개 메타데이터는 2023년 6월의 게시 날짜를 기록하지만, 그것은 검증된 최종 업데이트 타임스탬프가 아닙니다. 컬렉션은 활성latest버전 태그를 통해 가져와졌습니다. 운영자에게 중요한 것은 날짜로 어느 페이지가 더 최신인지 추측하는 것이 아니라, LACNIC이 모든 표면에서 하나의 권위적 버전 식별을 공개하는 것입니다.

두 번째 수리는 트랜잭션적입니다. 완전한 목록은 그것이 준비된 기준 상태의 식별자를 함께 전달해야 합니다. 불투명 리비전, ETag, 정규화된 목록 해시 또는 다른 서버 발급 토큰이 될 수 있습니다. 형식보다 규칙이 중요합니다. 조직의 현재 목록이 여전히 내가 검토한 기준일 때에만 이 교체를 수락하라. 오래된 기준은 변경 없이 끝나는 충돌을 만들어야 합니다.

세 번째 수리는 설명적입니다. 커밋 전에 드라이런 또는 사전 점검이 의도된 추가, 수정, 삭제, 프리픽스·원점 AS·maxLength의 변경을 포함해 반환해야 합니다. 명시적 삭제와, 클라이언트가 불완전한 로컬 모델을 직렬화해 사라진 항목을 구분해야 합니다. 검증 오류와 오래된 상태 충돌은 변경 후에 재구성되는 것이 아니라 변경 전에 나타나야 합니다.

네 번째 수리는 근거적입니다. 성공하거나 거부된 시도는 하나의 원자적 작업 식별자, 계약 버전, 수락된 기준 식별자, 결과 식별자, 한정된 결과를 반환해야 합니다. 정정은 자신이 대체하는 작업을 가리켜야 합니다. 인증된 조직에는 그 연쇄가 필요하고, 공개에는 개인 계정 이름, 보안 통제 또는 자격 증명이 필요하지 않습니다.

계약 요소닫아주는 것
경로 및 스키마 버전어떤 공개 쓰기 의미가 요청을 지배했는지
조직 및 기준 목록 식별자클라이언트가 교체하려 한 관찰된 상태가 어느 것인지
명시적 추가/변경/삭제 차이완전한 페이로드가 무엇을 하려 한 것인지
드라이런 또는 사전 점검검증과 오래된 상태가 변경 전에 발견되었는지
원자적 작업 및 결과 식별자하나의 완전한 전환이 수락, 거부 또는 재시도되었는지
대체 관계 포인터이후 정정이 이력을 재작성하지 않고 보존하는 방식

이 항목은 새로운 거버넌스 프로세스보다 작습니다. API가 자신의 전환에 대해 진실을 말하도록 요청하는 것입니다. LACNIC의 효율적일 수 있는 원하는 상태 설계를 유지하고, 조직이 자신의 권한에 대한 권위를 유지하며, 경로 표만으로는 제공할 수 없는 제어 증명 경계를 자동화에 부여합니다.

LACNIC의 공개 RPKI 자료는 올바른 ROA를 만들고 잘못된 것을 바로잡는 실무적 중요성을 강조합니다. 그 API는 그 운영적 필요를 반복 가능한 자동화로 바꿀 수 있습니다. 남은 작업은 자동화된 단위를 모호하지 않게 만드는 것입니다. 운영자가 어느 표의 일련번호를 믿을지 선택하거나, 최신 문서 링크를 따라간 뒤에야 실제 공개 계약이 목록 전체임을 발견하도록 두어서는 안 됩니다.

출처