요약

  • Job Snijders와 RIPE NCC의 Ties de Kock는 2024년 12월 나온 IETF 표준 RFC 9697을 함께 썼다.
  • 검증기는 전에 본 일련번호와 해시를 대조한다. 옛 델타의 해시가 바뀌면 경고하고 최신 전체 스냅샷으로 다시 맞춘다.

1774번 서랍에 다른 파일이 들어왔다

RFC 9697의 예시에서 저장소의 업데이트 알림은 일련번호 1774에서 1775로 나아간다. 정상적인 흐름이다. 그런데 새 알림에 적힌 옛 번호 1774의 해시가 전과 다르다. 1773의 해시는 그대로다. 서랍에 붙은 번호표는 같지만 안의 서류가 바뀐 셈이다. RFC의 숫자는 이 고장을 설명하기 위한 예시다. Job Snijders와 공동 저자 Ties de Kock는 이 어긋남을 검증 가능한 신호로 만들었다.

RPKI 저장소는 네트워크가 경로의 출발지를 확인할 때 쓰는 서명된 자료를 배포한다. RRDP는 변경분을 작은 델타 파일로 나른다. 검증기는 처음에 전체 스냅샷을 받은 뒤, 이후에는 빠진 델타만 내려받는다. 업데이트 알림에는 세션, 일련번호, 각 파일의 해시가 담긴다. 정적 파일과 웹 캐시를 쓸 수 있어 효율적이다. 그 효율은 같은 번호의 오래된 파일이 계속 같은 내용을 가진다는 약속 위에 선다.

서로 다른 시간에 접속한 두 검증기는 1774번에서 다른 내용을 받아도 같은 세션과 같은 최신 번호를 표시할 수 있다. 두 숫자만 비교하는 감시 화면은 일치를 선언한다. 실제로는 로컬 저장소가 갈라졌다. 두 저자가 제시한 방법은 마지막으로 정상 수신한 알림의 일련번호와 해시 쌍을 저장하는 것이다. 다음 알림이 오면 두 알림에 함께 있는 번호를 대조한다. 오래된 번호의 해시가 바뀌었다면 경고를 띄우고 최신 전체 스냅샷을 받아 다시 시작한다.

Snijders는 파일 배포의 골칫거리를 일찍부터 기록했다. 2021년 rpki-client 구현을 설명한 글에서는 부하 분산 뒤의 서버들이 서로 다른 속도로 갱신되는 사례를 다뤘다. 한 서버는 새 델타를 알리는데 다른 서버는 아직 그 파일을 내줄 수 없었다. 그것은 서버 간의 경주이고, RFC 9697은 옛 델타가 제 번호 아래에서 바뀌는 경우를 다룬다. 두 고장은 다르지만 서명된 데이터도 제대로 전달돼야 쓸 수 있다는 사실은 같다.

결과는 라우팅 판단에 닿는다. RFC에 따르면 동기화가 어긋난 캐시는 인증기관이 철회하려던 검증 자료를 계속 내보내거나 필요한 자료를 빠뜨릴 수 있다. valid여야 할 경로가 한동안 unknown 또는 invalid로 보일 수 있다. 저장소 세션은 몇 달 동안 이어지기도 한다. 어제의 해시를 기억하는 이유가 바로 여기 있다.