요약

  • RRDP 장애 시 검증기는 이전 캐시를 재사용하거나 훨씬 큰 스냅샷을 요청하거나 rsync로 대체할 수 있으며, 이 선택은 보편적인 복구 타이머가 아니라 구현과 운영자 정책에 의해 결정됩니다.
  • 리포지토리 델타 보존, 매니페스트 신선도, 검증기 임계값은 비용을 게시 서비스, 네트워크 운영자, 전파를 기다리는 라우팅 의사 결정을 가진 자원 보유자 사이에 분산시킵니다.
  • 운영자에게 필요한 것은 녹색 엔드포인트 모니터가 아니라 리포지토리별 복구 접수증과 독립적인 검증 페이로드 비교입니다.

오전 9시, 어떤 검증기가 RPKI 리포지토리에 다음 작은 델타를 요청합니다. 참조는 존재하지만 파일이 없습니다. 한 검증기는 어제 성공한 캐시를 재사용합니다. 다른 하나는 전체 스냅샷을 요청합니다. 세 번째는 rsync로의 지연된 대체를 시작합니다. 세 가지 모두 방어 가능한 복구 정책을 따른다고 주장할 수 있지만, 어느 것도 불용 파일을 더 세심히 들여다봄으로써 새로운 ROA를 발견하지는 못합니다.

이 시퀀스가 RPKI 리포지토리 복구가 라우팅 제어 표면이 되어가고 있는 이유입니다. Resource Public Key Infrastructure는 보통 서명된 객체에서 바깥쪽으로 설명됩니다. 보유자가 오리진을 승인하고, 신뢰 당사자가 이를 검증하며, 라우터가 오리진 검증 정책을 적용합니다. 그러나 운영 체인은 그보다 앞에서 시작됩니다. 서명된 의사 결정은 인증 기관을 떠나 게시를 거쳐 리포지토리 전송을 통해 도착하고, 매니페스트와 인증서 검사를 통과하며, 검증된 페이로드가 되어야 합니다. 전송 장애는 모든 서명이 수학적으로 온전하더라도 이후 단계에 제공되는 증거를 바꿉니다.

델타, 스냅샷, 대체

RFC 8182는 RRDP에 세 가지 유용한 요소를 제공합니다. 알림 파일은 리포지토리 세션과 시리얼을 식별합니다. 델타 파일은 증분 변경을 담고, 스냅샷은 완전한 현재 뷰를 담습니다. 검증기가 연속된 델타 체인을 가지고 있다면 저렴한 경로는 그것을 적용하는 것입니다. 델타를 사용할 수 없거나 거부되면 프로토콜은 신뢰 당사자를 스냅샷으로 안내합니다.

비대칭이 중요합니다. 증분 업데이트는 작을 수 있지만 스냅샷은 수십 또는 수백 메가바이트에 이를 수 있습니다. 최신SIDROPS 게시 서비스 초안은 실패 사다리를 명확히 서술합니다. 검증기가 하나 이상의 델타에서 실패하면 더 큰 스냅샷을 시도하고, 이어 rsync로 대체할 수 있습니다. 다음 RRDP 실행에서는 보통 다시 스냅샷부터 시작합니다. 따라서 과부하된 서비스는 실패에 대한 응답으로 더 큰 수요를 만들어낼 수 있습니다. 복구 객체는 시스템이 그것을 제공할 능력이 가장 낮을 때 정확히 더 커집니다. 분산 시스템은 과연 아이러니를 즐깁니다.

이 초안은 아직 RFC가 아니라 진행 중인 작업입니다. 그럼에도 운영 증거는 구체적입니다. 2024년 1월 한 대형 리포지토리에서 14시간에 걸쳐 144개의 델타를 담은 알림은 55.5TB 트래픽 중 251GB, 즉 0.5% 미만을 차지했습니다. 더 많은 델타를 보존하면 뒤처진 검증기가 증분 방식으로 복구할 수 있지만 모든 알림을 더 크게 만듭니다.

더 적게 보존하면 일상적인 알림 바이트를 절약하고 더 많은 뒤처진 클라이언트를 스냅샷으로 밀어냅니다. 초안은 일부 검증기가 2024년에 1~2시간 간격으로만 동기화하는 것이 관찰되었기 때문에 최소 4시간 분량의 델타를 권고합니다. 공짜 보존 설정은 없으며, 존재하는 것은 언제 어디에 대역폭을 쓸지에 대한 결정뿐입니다.

검증기는 또 하나의 정책 계층을 더합니다. 현재Routinator 문서는 RRDP 실패 후 rsync 대체에 대해never,stale,new정책을 노출합니다. 문서화된 기본값은stale입니다. 즉, 로컬 RRDP 사본이 최신으로 간주되는 동안 이를 사용하고, 그 후 새로 고침 주기와 최대 대체 시간 사이에서 무작위로 선택된 리포지토리별 간격 후에 rsync를 시도합니다. 문서화된 최대값의 기본값은 3,600초입니다. 이 무작위화는 모든 검증기가 함께 옆문으로 몰려오도록 초대하는 대신 rsync 부하를 분산시킵니다.

Routinator는 복구 경로를 바꿀 수 있는 임계값도 문서화합니다. 100개를 초과하는 델타가 필요하면 스냅샷을 사용하고, 500개를 넘는 델타 목록은 비어 있는 것으로 취급하며, RRDP 자원 검색에는 600초, 읽기 작업에는 10초, rsync 명령에는 300초를 허용합니다. 이것들은 자연의 상수가 아니라 제품 기본값입니다. 이를 바꾸면 동일한 리포지토리 장애가 서로 다른 네트워크 요청 시퀀스와 캐시 결정으로 변할 수 있습니다.

캐시는 증거의 일부

RFC 9286은 페치 실패 후 검증기가 해야 할 일을 설명합니다. 이후 페치가 성공할 때까지 이전 성공 페치의 데이터를 사용하라는 것입니다. 이는 불완전한 리포지토리 뷰가 잘못된 라우팅 판단으로 이어지는 것을 막습니다. 동시에 이는 리포지토리 가동률이 라우터가 결국 받을 증거의 연령에 대한 이진 대리 지표가 아니라는 것을 의미합니다.

매니페스트는 그 연속성을 경계 짓습니다. 매니페스트는 발급자가 게시하려는 객체를 열거하고 신뢰 당사자가 삭제, 대체, 은폐를 감지하도록 돕습니다. 매니페스트는 불완전하거나 낡은 뷰를 드러낼 수 있지만 복구할 수는 없습니다. 매니페스트의 갱신 시점은 CRL과 객체 유효성과 함께 캐시 재사용을 유한한 운영 창으로 만듭니다.

2026년 게시 서비스 초안은 이 절충을 최적화로 없앨 수 있다고 가장하지 않고 서술합니다. 더 긴 매니페스트와 CRL 유효 기간은 운영자에게 복구 시간을 더 주지만 재생(replay) 노출을 늘립니다. 더 짧은 유효 기간은 노출을 줄이고 재발행 churn을 늘립니다.

한 대형 리포지토리에서 재발행 주기를 24시간마다에서 48시간마다로 바꾸자 데이터 사용량이 약 절반으로 줄었습니다. 일상적인 매니페스트와 CRL 재발행이 대부분의 변경을 차지했기 때문입니다. 이것은 하나의 리포지토리 관찰이지 전역 변환 계수가 아닙니다. 그럼에도 누가 지렛대를 쥐고 있는지 보여주기에 충분합니다. CA가 유효성 리듬을 선택하고, 게시 서비스와 모든 신뢰 당사자가 그 결과로 생기는 churn을 처리합니다.

표준은 복구 경계를 계속 명확히 하고 있습니다. 2026년 5월에 발행된RFC 9981은 매니페스트 번호가 최대치에 도달하는 예외 사례를 다룹니다. 이 문서는 구현들이 이전에 서로 다르게 대응할 수 있었다고 기록합니다. 어떤 구현은 만료 후에만 교체를 수용했고, 다른 구현은 새 매니페스트를 무기한 거부했습니다. 그리고 파일명 기반 리셋 규칙을 명세합니다. 산술적으로 우연한 고갈이 일상적인 카운팅보다 더 개연성이 있습니다. 더 넓은 요점은 이 사건이 흔하다는 것이 아닙니다. 규격에 명시되지 않은 복구 가장자리가 준수하는 구현들 사이에서도 서로 다른 사용 가능한 증거를 만들 수 있다는 점입니다.

용량과 보안은 같은 방향으로 실패하지 않는다

rsync로 대체하면 도달성은 개선될 수 있지만 전송 경계는 악화됩니다. RRDP는 HTTPS를 사용하며 불변 스냅샷과 델타를 캐시 가능하게 만듭니다. rsync는 연결당 더 많은 서버 작업을 요구하고 자체 채널 기밀성과 무결성이 없습니다. Routinator의위협 모델에 따르면 경로상 공격자는 다운그레이드를 강제할 수 있으며, 그 경우 서명 객체와 매니페스트 검사가 방어에서 더 큰 비중을 담당하게 됩니다.

NLnet Labs는 2020년에 의도적으로 미래지향적인 모델로 이 용량 문제를 보여주었습니다. 150,000개의 검증기가 10분마다 폴링하면 초당 약 250건의 요청이 되며, 당시 약 3건 정도에 익숙했던 rsync 서비스와 비교됩니다. 이것은 2026년 트래픽 수치가 아닙니다. 즉각적이고 보편적인 대체가 나쁜 기본값이었던 이유, 그리고 오늘날 무작위화된 경계가 존재하는 이유를 설명합니다.

간단한 민감도 계산은 인터넷을 측정한다고 가장하지 않으면서 지렛대의 크기를 보여줍니다. 10,000개의 검증기가 보통 1MB의 증분 전송이 필요하고, 전체 압축 스냅샷이 100MB라고 가정합니다. 모두 증분을 유지하면 한 업데이트 주기는 10GB입니다. 20%가 스냅샷으로 밀려나면 대략 208GB가 됩니다. 8,000MB의 델타와 200,000MB의 스냅샷입니다. 재시도와 rsync 서버 작업은 그 위에 얹힙니다. 핵심 변수는 검증기가 몇 개 존재하는지가 아니라 그 복구 시도가 시간적으로 얼마나 촘촘히 겹쳐지는가입니다.

이 때문에 리포지토리가 "가동 중"이면서도 결함이 있는 복구 제품을 제공할 수 있습니다. 로드 밸런서는 참조된 스냅샷이나 델타가 다른 백엔드에 도달하기 전에 한 백엔드의 알림을 노출할 수 있습니다. 낡은 keepalive 연결은 페일오버를 넘어 더 오래된 세션을 반환할 수 있습니다. 현재 SIDROPS 초안은 일관된 백엔드 뷰를 요구하며, RFC 8182가 시리얼 회귀에 대한 보편적인 응답을 정의하지 않는다는 점을 경고합니다. 일부 검증기는 재동기화를 위해 스냅샷을 페치합니다. 엔드포인트 가용성은 200 응답을 봅니다. 검증기는 깨진 타임라인을 봅니다.

이 소스 집합은 그런 분기의 전역 비율을 확립하지 않으며, 특정 리포지토리가 라우팅 중단을 일으켰다는 것을 증명하지도 않습니다. 이는 메커니즘, 구성 가능한 선택, 비용 전이를 확립합니다. 운영자가 시험하기에 충분합니다.