요약

  • ARIN은 각 고객 ASN(Customer ASN)에 고유한 ASPA를 부여하고, 자원 보유자가 자신의 공급자 AS 집합을 수정할 수 있게 한다. 따라서 운영상의 작업은 트랜짓 사업자 하나를 추가하거나 제거하려는 인간의 의도가 단순하더라도, 전체 집합의 교체이다.
  • ARIN은 RPKI 데이터베이스에서의 즉시 적용, 24시간 이내 공개 저장소 반영, 수분마다 이루어지는 저장소 갱신, 그리고 독립 검증기(밸리데이터)를 통한 확인을 구분한다. 이들은 하나의 '성공' 순간이 아니라 서로 다른 상태들이다.
  • 유효한 IETF 초안은 집합이 비투명 라우트 서버를 포함한 모든 공급자의 합집합이어야 한다고 규정하며, 사용 가능한 집합에 존재하지 않는 공급자를 No Attestation과 구분한다. 구성원이 누락되는 것이 중요할 수 있지만, 그렇다고 영향을 받는 모든 경로가 자동으로 무효가 된다는 것을 증명하지는 않는다.
  • 프라이버시를 고려한 차이 영수증(diff receipt)은 권한이 부여된 이전 집합, 제출된 완전한 이후 집합, 원자적 트랜잭션 결과, 발급된 객체, 공개 관측, 검증기 관점을 결합해야 한다. 계약이나 비공개 토폴로지를 공개하지 않으면서 상태 충돌을 드러내야 한다.

ASPA 변경에서 위험한 단어는 '하나'이다. 새로운 트랜짓 사업자 하나. 라우트 서버 하나. 예비 회선 하나. 계약 종료 후 제거되는 ASN 하나. 티켓은 상업적 이벤트가 원자적이기 때문에 원자적으로 들린다. 그러나 서명된 객체는 그렇지 않다. 그 객체는 고객 ASN의 공급자 집합을 표현하며, 구성원 하나를 바꾸려면 변경 이후에도 참이어야 하는 집합을 제출해야 한다.

이 차이가 일상적인 편집을 상태 결정으로 바꾼다. 권한이 부여된 집합이{A, B}이고 의도한 집합이{B, C}라면, 유용한 근거는 단순히 C가 추가되었다는 것이 아니다. A가 제거되었고, B가 유지되었으며, C가 나타났고, 변경을 수행한 사람 또는 자동화가 시스템이 교체하려는 이전 상태와 동일한 이전 상태를 보았다는 사실이다. 그 계보가 없다면, 녹색 트랜잭션 결과는 너무 적은 것을 증명한다.

ARIN의 구현은 이 상태 모델을 이례적으로 잘 드러낸다. ARIN의 안내에 따르면 각 고객 ASN마다 고유한 ASPA 객체를 생성해야 한다. ARIN Online에서는 보유자가 그 객체에 부착된 공급자 AS 집합을 수정한다. REST 인터페이스 역시 고객 ASN과providerAsIds를 담는 ASPA 삭제 및 추가 요소를 설명한다. ASPA와 ROA 작업을 하나의 트랜잭션으로 결합할 수 있고, 모든 요소가 함께 성공하거나 함께 실패한다.

원자성은 가치 있다. 제출된 번들 중 한쪽 절반이 실패하는 동안 다른 절반만 레지스트리 상태가 되는 일을 막아준다. 그러나 원자성은 좁은 질문에 답한다. ARIN이 이 요청 번들을 하나의 단위로 받아들였는가? 그것은 요청이 최신 권한 집합을 기반으로 했는지, 발급된 객체가 특정 시점에 공개 저장소에서 보였는지, 혹은 의존 당사자(relying party)가 이를 가져와 해석했는지를 운영자에게 알려주지 않는다.

이 구분들은 서비스 밖에서 만들어진 이론적 구분이 아니다. ARIN의 ASPA 페이지 스스로 이를 분리한다. 변경 사항은 RPKI 데이터베이스에서 즉시 효력이 발생하고 24시간 이내에 공개 저장소에 나타난다고 명시한다. 또한 저장소는 수분마다 갱신되며, ASPA가 활성화되었는지 확인하려면 RPKI 검증기를 사용하라고 조언한다. 데이터베이스 커밋, 저장소 객체, 검증기 관측은 하나의 체인 위에 있는 세 지점이다.

목록이 집합이라는 사실을 숨길 수 있다

대부분의 인터페이스는 집합을 목록처럼 보이게 만든다. ASN을 한 줄에 하나씩 표시하고, 추가와 삭제를 받아들이고, 확인 메시지를 돌려준다. 그런 표현은 사용자가 델타(delta)로 사고하게 만든다. 그러나 의존 당사자가 소비하는 암호학적 명세는 상태이다.

유효한 ASPA 프로필 초안은 비투명 라우트 서버 AS를 포함해 모든 공급자 AS를 나열해야 한다고 규정한다. 동일한 고객 ASN에 대해 여러 유효한 ASPA 객체가 존재하면, 의존 당사자들은 그 합집합을 구성한다. 그럼에도 초안은 유효 구간이 경쟁 조건(race condition)을 일으킬 수 있으므로 여러 객체를 피하라고 권고한다. 이를 보완하는 검증 초안 역시 고객의 SPAS를 모든 공급자의 합집합으로 보고 ASPA 객체 하나를 권고한다.

여기서의 편집적 주의가 중요하다. 이것들은 최종 RFC가 아니라 인터넷 초안(Internet-Draft)이다. 버전별 텍스트는 바뀔 수 있다. 그러나 이 초안들은 여전히 구현되고 검증되고 있는 의미론에 대한 현재 최선의 설명이며, 편집이 고립된 체크박스로 안전하게 이해될 수 없는 이유를 보여준다.

한 운영자에게 일반 트랜짓 사업자 둘과 비투명 라우트 서버 하나가 있다고 하자. 변경 관리자가 어제 상태를 기준으로 한 화면에서 세 번째 트랜짓 사업자를 추가하는 동안, 네트워크 엔지니어가 다른 세션에서 이미 라우트 서버를 추가했다. 두 사람 모두 완전한 교체 집합을 제출하고 시스템이 이를 순서대로 받아들이면, 나중 트랜잭션이 잘못된 형식 없이도 먼저 추가된 구성원을 지워버릴 수 있다. 각 행위자는 '내 변경은 성공했다'고 정직하게 말할 수 있다. 그 결과 집합은 여전히 틀릴 수 있다.

이것은 라우팅 결과를 가진 갱신 유실(lost-update) 문제이다. 요청된 추가만 기록해서는 해결되지 않는다. 서비스는 요청자가 권한을 부여한 이전 상태, 최소한 그 표준 다이제스트를 알아야 한다. 그러면 compare-and-set 사전 조건이 낡은 상태를 기준으로 한 요청을 거부할 수 있다. 그 거부는 어느 공급자 관계가 실제인지를 결정하지 않는다. 새 서명 객체가 발급되기 전에 사람 또는 자동화가 그 결정을 조정하도록 강제한다.

No Attestation은 Not Provider+와 같지 않다

검증 초안은 집합 경계에 운영적 의미를 부여한다. 고객에 대해 사용 가능한 ASPA 항목이 없을 때, 공급자 승인 결과는 No Attestation이다. 공급자가 사용 가능한 공급자 집합에 존재하면 결과는 Provider+이다. 고객이 사용 가능한 집합을 갖고 있지만 공급자가 없으면, 결과는 Not Provider+이다.

이 라벨들을 맥락 없이 '유효'와 '무효'로 뭉뚱그려서는 안 된다. 전체 AS 경로 검증은 방향, 경로 구간, 그리고 이용 가능한 승인을 평가한다. 초안이 경고하듯 누락된 공급자가 나중에 경로가 잘못된 ASPA Invalid가 되는 데 기여할 수 있으나, 누락된 ASN을 사용하는 모든 경로가 어디서나 자동으로 무효라고 주장하는 것은 정확하지 않다. 더 예리한 요점은 이것이다. 객체를 삭제하는 것과 비어 있지 않은 객체에서 한 구성원을 실수로 빼뜨리는 것은 의미상 서로 다른 행위라는 점이다.

그 차이 때문에 영수증에는 이전과 이후의 전체 집합이 필요하다. '공급자 A를 제거했다'는 기록은 결과 상태가 No Attestation이었는지{B, C}였는지 확정할 수 없다. 'C를 추가했다'는 기록은 B가 보존되었는지 보여주지 못한다. 화면 캡처는 하나의 브라우저가 렌더링한 것을 보여줄 수 있으나, 표준 요청 바이트, 인증된 트랜잭션, 발급된 객체, 의존 당사자 관측을 반드시 보여주지는 않는다.

예비 회선은 타이밍 문제를 더 어렵게 만든다. 검증 초안은 예비 또는 긴급 공급자를 사전에 등록하라고 권고한다. 그 조언은 장애 조치의 논리를 따른다. 트래픽이 우회 경로로 옮겨가기 전에 승인이 사용 가능해야 한다는 것이다. 실패가 시작된 뒤에 공급자를 추가하면, 레지스트리 수락, 저장소 게시, 검증기 갱신이 복구 시계의 일부가 된다. 영수증은 모든 의존 당사자가 동시에 수렴한다고 약속하지 않으면서도, 그 시계들을 측정 가능하게 만들어야 한다.

녹색 결과 뒤에 있는 네 개의 시계

첫 번째 시계는 승인이다. 자원 보유자 또는 위임된 자동화가 완전한 공급자 집합이 무엇이어야 하는지 결정하는 시점에 시작된다. 그 근거는 보았던 이전 집합, 승인된 이후 집합, 그리고 그 결정을 내릴 수 있도록 허용된 신원 클래스 또는 역할이다. 실명 직원이 공개 기록에 나타날 필요는 없다.

두 번째 시계는 트랜잭션이다. ARIN은 요청 접수, 인증, 검증, 원자적 수락을 기록할 수 있다. 요청이 ROA와 ASPA 요소를 모두 포함하면, 트랜잭션 식별자는 관련 없는 운영 세부사항을 영수증에서 제외하면서도 이들을 묶을 수 있어야 한다. 실패는 이전 상태를 그대로 두어야 하고, 성공은 발급 상태 다이제스트를 식별해야 한다.

세 번째 시계는 게시이다. ARIN은 자신의 데이터베이스는 즉시 변경되고 공개 저장소에 나타나는 데 최대 24시간이 걸릴 수 있으며, 일반적인 저장소 갱신은 수분마다 이루어진다고 말한다. 그 외부 한계는 정상 게시가 하루 걸린다는 근거가 아니다. 그 객체의 실제 첫 관측, 그 해시, 그리고 관련 매니페스트 또는 저장소 참조를 기록해야 하는 이유이다.

네 번째 시계는 소비이다. 검증기는 저장소 자료를 가져오고, 체인을 검증하고, 사용 가능한 공급자 집합을 구성해야 한다. 그 관측은 명시된 시점의 특정 감시 지점(vantage)과 소프트웨어 빌드에 귀속된다. 다른 의존 당사자들은 서로 다른 일정으로 갱신하거나, 로컬 사유로 체인을 거부하거나, 다른 코드를 실행할 수 있으므로, 이는 보편적 수렴을 증명하지 않는다.

이 시계들이 하나의 '갱신됨' 타임스탬프로 뭉뚱그려지면, 사고 검토는 경계를 찾을 수 없다. 제출된 상태가 틀렸을 수도 있고, 트랜잭션이 실패했을 수도 있고, 객체가 아직 관측되지 않았을 수도 있고, 검증기가 낡았을 수도 있다. 각 조건은 서로 다른 대응을 요구한다. 하나의 상태 표시등은 이들을 구분하지 못한다.

차이 영수증에 담겨야 할 것

영수증은 고객 ASN과 발급 인증서 또는 CA 맥락으로 시작한다. 표준 이전 공급자 집합, 혹은 이전 서명 객체에 대한 내구성 있는 참조가 결합된 다이제스트를 기록한다. 완전한 제출 이후 집합을 안정적인 정렬 순서로 기록한다. 그 두 상태로부터 추가, 제거, 불변 ASN을 도출한다. 차이는 근거이지 진실의 원천이 아니다. 완전한 집합들이 원천이다.

비투명 라우트 서버를 식별하고, 운영자가 그런 운영 메타데이터를 유지하기로 선택한 경우 예비 또는 긴급 역할을 선택적으로 라벨링해야 한다. 그런 라벨이 ASPA 페이로드에 들어갈 필요는 없다. 그들은 구성원이 포함된 이유를 설명하고, 변경 관리자가 바로 실패를 위해 예약되어 있기에 조용한 경로를 실수로 제거하는 일을 막는 데 도움을 준다.

트랜잭션 구역은 요청 식별자, 인증된 행위자 클래스, 제출 집합 해시, compare-and-set 사전 조건, 수락 시각, 결과를 담아야 한다. 작업이 ROA와 ASPA가 섞인 트랜잭션의 일부였다면, 영수증은 그 관계와 전부 아니면 전무(all-or-nothing) 결과를, 공개 대상에게 관련 없는 프리픽스를 노출하지 않고 명시할 수 있다.

게시 구역은 발급된 ASPA 객체 해시, 저장소 또는 매니페스트 참조, 정의된 감시 지점으로부터의 첫 관측 시각을 식별해야 한다. 검증기 구역은 감시 지점, 검증기 소프트웨어와 버전, 조회 시각, 관측된 사용 가능 공급자 집합, 그리고 No Attestation, Provider+, Not Provider+ 사이에서 검증된 전환이 있다면 그것을 명시해야 한다.

마지막으로 영수증 자체의 수명 주기 링크가 필요하다. 대체됨(superseded by), 정정됨(corrected by), 만료 시점(expired at), 롤백 대상(rolled back to)이다. 롤백은 또 하나의 완전 집합 결정이며 역사의 지우개가 아니다. 잘못된 공급자가 제거되었다면, 근거는 결함 상태와 정정된 상태를 모두 보여야 하며, 대상에 맞는 접근 통제를 적용한다.

이 기록은 압축적일 수 있다. 대부분의 필드는 해시, 식별자, 타임스탬프, 작은 ASN 집합이다. 매 편집마다 서술 문장이 필요한 것은 아니다. 의도에서 관측까지 이어지는 기계 판독 가능한 체인, 그리고 무엇이 바뀌었고 무엇이 아직 검증되지 않았는지 말하는 사람용 요약이 필요할 뿐이다.

프라이버시는 계보 누락의 변명이 되지 못한다

ASPA의 공급자 ASN은 RPKI를 통한 공개 소비를 위한 것이다. 그렇다고 그 관계에 관한 모든 사실이 공개인 것은 아니다. 계약, 가격, 트래픽 규모, 연락처 성명, 유지보수 창, 자격 증명, 내부 토폴로지는 비공개로 남을 수 있다. 공개 영수증은 서명된 집합, 상태 다이제스트, 대략적인 행위자 역할, 관측 근거를 보여줄 수 있다. 더 풍부한 구성원용 뷰는 내부 승인 과정을 보존할 수 있다.

같은 비례성이 검증기에도 적용된다. '감시 지점 X가 시각 Z에 버전 Y로 관측함'을 게시하면 그 검증은 재현 가능해진다. '인터넷이 수렴했다'는 단정을 게시하는 것은 근거를 넘어선다. 서비스는 여러 독립 관측을 제공할 수 있으나, 각각은 하나의 관점이지 신탁이 아니다.

시간 경계 역시 프라이버시이자 운영적 안전장치다. 영수증에는 내구성 있는 무결성이 필요하지만, 상세한 행위자와 워크플로우 메타데이터가 영원히 공개된 채로 남을 필요는 없다. 오래 지속되는 공개 계층은 암호학적 체인과 상태 전이를 보존할 수 있고, 제한된 기록은 조직의 보존 규칙을 따른다.

이것은 통제 제안이지 의혹 제기가 아니다

ARIN은 2026년 3월에 ASPA가 ARIN Online에서 완전히 사용 가능해졌다고 발표했다. 가용성은 서비스를 사용할 수 있다고 말할 뿐이다. 그것은 채택을 확립하지 않고, 오류를 증명하지 않으며, 배포 결정을 운영자에게서 레지스트리로 넘기지도 않는다.

ARIN 자신의 공개 논의는 그 경계를 지켰다. ARIN 57에서 John Curran은 ASPA를 구현하고 설명하는 역할을 언급하면서, 운영자가 배포해야 한다고 말하는 것은 ARIN의 일이 아니라고 했다. 차이 영수증은 그 제한된 역할에 맞는다. 어떤 ASN이 ASPA를 필요로 하는지, 어느 공급자가 그 안에 속하는지를 결정하지 않는다. 승인된 결정을 사후에 검열 가능(inspectable)하게 만들 뿐이다.

여기에는 ARIN이 공급자 집합을 잃었거나 잘못 게시했다는 증거가 없다. 어떤 경로가 ASPA Invalid가 되었다는 주장도 없다. 24시간 문구는 관측된 지연으로 취급되지 않는다. 이 논증은 서비스가 문서화한 상태 전이와 초안들의 완전 집합 의미론에서 나온다.

그것으로 충분하다. 통제는 공개적 실패가 일화를 제공하기 전에 설계되는 경우가 많다. 이전 상태를 보존하는 값싼 순간은 편집이 이루어질 때이다. 나중에 이를 재구성한다는 것은 하나의 기록으로 묶이도록 설계되지 않은 브라우저 기록, API 로그, 오래된 저장소 객체, 검증기 캐시를 찾아다니는 일을 뜻한다.

ASPA 편집은 상업적 의도로는 작지만 의미적 범위는 클 수 있다. 운영자는 공급자 하나로 생각하고, 의존 당사자는 전체 집합을 소비한다. ARIN은 두 상태를 모두 이름으로 밝히고, 그 결정을 독립 검증기가 볼 때까지 따라가는 영수증으로 그 간극을 좁힐 수 있다.

녹색 확인은 근거의 끝이 아니라 시작이어야 한다.

출처