요약

  • 10월 20일 나온 OpenBSD 8.0 릴리스 기록은 rpki-client가 신뢰 앵커 제약을 BGPsec 라우터 인증서에 올바르게 적용한다고 밝혔다.
  • 로컬 제약은 한 검증기가 받아들이는 자원 범위를 좁힌다. 신뢰 앵커의 게시 행위나 다른 검증기의 판단까지 통제하지는 않는다.

울타리에 문이 하나 더 생겼다

OpenBSD 8.0 릴리스 페이지는 rpki-client(8)가 BGPsec 라우터 인증서에 제약을 제대로 적용하도록 수정했다고 한 줄로 적었다. 상세 변경 기록에도 같은 항목이 있다. 새 버전은 10월 20일 공개됐다.

여기서 중요한 것은 기능이 있느냐보다 인증서 종류마다 같은 검사가 실행되느냐다. BGPsec 라우터 인증서는 BGPsec에 쓰는 키와 인터넷 번호 자원을 연결한다. OpenBSD의 기록은 rpki-client가 이제 이 인증서 종류에도 제약을 제대로 적용한다고 확인한다. 공개된 기록에는 이전 영향 버전이나 사고가 적혀 있지 않다. 확인 가능한 사실은 코드 수정이다.

이 수정은 IETF SIDROPS의 「Constraining RPKI Trust Anchors」 초안과 맞닿아 있다. -02판은 RPKI를 검증하는 각 당사자(RP)가 신뢰 앵커(TA)에 기대하는 자원 범위를 로컬에서 정하도록 제안한다. RP는 최종 엔티티 인증서에 적힌 IP 주소와 AS 번호를 로컬 허용 목록과 대조한다. 범위를 벗어나면 해당 RP는 그 서명 객체를 검증 과정에서 거부한다.

‘모든 자원’은 너무 넓은 위임장

초안에 따르면 다섯 지역 인터넷 레지스트리(RIR)는 통상 운영에서 모든 자원을 TA 인증서 아래 종속 자원으로 열거한다. 레지스트리 정보가 잠시 어긋날 때 인증이 끊기는 일을 줄이기 위해서다. 특히 자원 이전 중에는 이런 여유가 도움이 된다. 반면 RP가 보는 서명 권한은 현재 레지스트리 보유분보다 넓을 수 있다.

.constraints 파일은 RP에 두 번째 판단 지점을 만든다. 이름이 같은 .tal 파일의 신뢰 앵커 하나에 제약 파일 하나가 대응한다. 운영자는 접두사, 주소 범위, AS 번호를 allow로 허용하고 deny로 예외를 낼 수 있다. 거부가 허용보다 우선하며, allow에 적히지 않은 자원은 기본 거부다. 한 구간을 빼려고 인터넷 전체를 허용 목록으로 옮겨 적을 필요는 없다.

형식 오류는 파일 전체를 무효로 만든다. 초안은 RP가 오류가 있는 제약 파일을 통째로 거부하고, 그 파일로 최종 엔티티 인증서를 검사하지 말라고 요구한다. 수정 전까지 해당 TA에 대한 로컬 제약 검사는 작동하지 않는다. 문법 검사, 배포, 업데이트 담당까지 보안 통제의 일부다.

적용 대상도 정해져 있다. ROA, ASPA, RSC, BGPsec 라우터 인증서처럼 RFC 3779 확장에서 IP 또는 AS 자원을 명시하는 객체다. 서명 TAL과 Manifest는 자원을 상속하므로 적용 범위 밖의 예로 든다. 이 규칙은 한 RP의 검증 결과를 좁힌다. 라우터가 어떤 경로를 채택하는지는 데이터 전달과 로컬 라우팅 정책을 거쳐 결정된다.

표준이 끝나기 전에 코드가 먼저 움직였다

현재 -02 초안은 진행 중인 Internet-Draft다. Datatracker가 표시하는 SIDROPS 상태는 “Waiting for Write-Up Revised I-D Needed – Issue raised by WGLC”다. 초안은 RFC 발행 단계에서 구현 현황 부록을 삭제할 예정이라고 쓴다.

기능은 이미 소프트웨어에 들어가 있다. 부록은 C로 작성된 rpki-client가 2023년부터 이 방식을 기본 활성화했다고 보고한다. Rust의 panda-rpki와 Go 구현도 언급한다. 저자들은 세 구현이 같은 OpenBSD fixture에서 같은 결과를 냈다고 적었다. IETF는 기고자가 제출한 구현 정보를 직접 확인하지 않았다고 덧붙인다. 따라서 이 기록은 보고된 구현과 공동 테스트 자료를 보여주지만 독립적인 상호운용성 감사는 아니다. OpenBSD 매뉴얼은 TA별 .constraints 파일과 로컬 allow·deny 규칙을 설명한다.

8.0의 수정은 오래된 기능도 특정 인증서 종류를 다르게 다룰 수 있음을 보여준다. 공개 변경 기록에는 영향받은 이전 버전과 정확한 코드 경로가 없다. 그 두 정보가 과거 영향 범위를 정할 것이다. 확인된 사실은 OpenBSD가 BGPsec 라우터 인증서에 제약을 적용하는 방식을 고쳤다는 점이다. 기능 이름만 확인하지 말고 객체 종류별로 시험해야 한다.

작은 파일의 배포에 반 년

초안은 운영체제나 외부 패키지로 제약 파일을 배포하는 유지관리자에게 사용자가 갱신하기까지 여섯 달이 걸릴 수 있다고 보고 계획하라고 권한다. 자원 보유와 이전 정책은 변한다. 로컬 목록도 자신이 관리한다고 내세운 범위를 따라가야 한다. 오래된 allow 규칙은 새로 정당해진 자원을 막을 수 있고, 빠진 규칙은 운영자가 의도한 것보다 넓게 허용할 수 있다.

NRO 2026–2028 전략은 Trust Anchor Constraints 문서 마련을 예정된 RPKI 업무로 열거한다. NRO RPKI 프로그램은 2025년에도 신뢰 앵커 설정 우려를 다룰 방안을 커뮤니티에 공개 의견으로 묻는 목표를 세웠다. 제도 문서와 구현 코드는 나란히 움직인다. OpenBSD 8.0은 구현 쪽에서 최근에 나온 증거다.

운영자가 확인할 것은 구체적이다. 파일이 의도한 자원 범위를 담았는가? 맞는 TAL과 연결됐는가? 패키지 갱신 때 새 파일이 배포되는가? 오류 없이 읽히는가? 사용하는 모든 인증서 종류에 같은 규칙이 적용되는가? OpenBSD의 한 줄은 마지막 질문을 점검표 맨 아래로 밀어둘 수 없게 했다.

출처