RPKI란 무엇인가? 라우팅 보안 입문 안내

웹사이트가 완벽하게 작동하더라도 접속할 수 없게 될 수 있다. 사이트의 네트워크와 방문자 사이 어딘가에서 다른 네트워크가 잘못된 경로를 공표할 수 있기 때문이다. 그러면 트래픽은 제대로 전달할 수 없는 곳으로 향하거나, 이를 가로채려는 누군가에게 향한다.

RPKI는 자원 공개 키 기반 구조(Resource Public Key Infrastructure)의 약자다. 네트워크가 중요한 주장 하나를 확인하도록 돕는다. ‘이 네트워크는 이 IP 주소들을 공표할 권한이 있는가?’ 이 검사를 이해하면 더 근본적인 질문도 드러난다. 검사가 의존하는 기록은 누가 통제하는가?

네트워크가 하는 주장부터 살펴보기

인터넷은 네트워크들의 네트워크다. 경계 게이트웨이 프로토콜인 BGP를 통해 네트워크들은 IP 주소 묶음에 도달하는 방법을 공표하고 교환한다. 이런 주소 묶음을 프리픽스라고 한다. 독립적으로 운영되는 각 라우팅 네트워크는 자율 시스템 번호, 즉 ASN으로 식별된다.

한 배송업체가 ‘우리는 이 동네에 배송할 수 있습니다’라고 알린다고 생각해 보자. 다른 업체들은 그 주장을 확인할 방법이 필요하다. 라우팅에서 잘못된 공표는 오타로 생길 수도 있고 의도적인 경로 탈취일 수도 있다. BGP 공표만으로는 경로의 원점으로 지목된 네트워크가 실제로 그 경로를 처음 공표할 권한이 있는지 증명할 수 없다.

RPKI, ROA, 검증이 각각 하는 일

RPKI는 인터넷 번호 자원을 위한 인증서 체계를 제공한다. 주소 보유자는 서명된 경로 원점 승인(Route Origin Authorisation, ROA)을 발행할 수 있다. ROA는 특정 프리픽스를 원점에서 공표할 수 있는 ASN을 명시한다. 지정된 경우에는 그 주소 범위를 공표할 때 얼마나 세밀하게 나눌 수 있는지도 정한다. 기술적 정의는 RFC 9582에 있다.

ROA를 발행하는 일과 수신한 경로를 검사하는 일은 별개다. 검증 소프트웨어가 인증서와 서명된 기록을 확인한 뒤, 검증된 승인 데이터를 라우터에 제공한다. 라우터는 경로 공표와 이 데이터를 비교하고, 사업자는 그 결과에 따라 적용할 라우팅 정책을 선택한다. 이 비교를 경로 원점 검증(Route Origin Validation, ROV)이라고 한다. RIPE NCC의 운영자 안내는 이 역할 분담을 설명한다.

배송의 예에서 한쪽은 누가 그 동네에 배송할 수 있는지 공표하고, 다른 쪽은 그 허가를 확인한다. 인증서는 이 시스템 안에서의 증거다. 이후의 모든 배송이 안전하다는 증명은 아니다.

단순한 예·아니요가 아닌 세 가지 결과

Valid(유효): 검증된 승인 중 적어도 하나가 공표된 프리픽스를 포함하고, 제시된 원점 ASN과 프리픽스 길이를 모두 허용한다. Invalid(무효): 이를 포함하는 승인들이 있지만 그 조합을 허용하는 승인은 없다. NotFound(찾지 못함): 검증 데이터에 이를 포함하는 승인이 없다.

NotFound는 공격자가 발견됐다는 뜻이 아니다. Invalid만으로도 원인이 공격인지 설정 오류인지 알 수 없다. RFC 6811에 정의된 대로, 이 상태들은 비교 결과를 나타낸다.

이 보호 장치가 알려 주는 것과 알려 주지 못하는 것

원점 검증은 네트워크가 승인되지 않은 원점을 거부하도록 도울 수 있다. 경로상의 모든 네트워크를 인증하거나 방문자의 연결을 암호화하지는 않으며, 웹사이트의 지속적인 가용성도 보장하지 않는다. 경로 유출은 승인된 원점을 그대로 유지해 이 검사를 통과할 수 있다. 필터링과 모니터링에는 여전히 할 일이 남는다. RPKI는 라우팅 보안의 한 부분이다.

사업자에게 유용한 준비는 실제 공표에서 시작된다. 어떤 프리픽스를 어떤 ASN으로 공표하는지, 발행된 승인이 그와 일치하는지 확인해야 한다. 기록과 검증기가 제대로 작동하도록 유지하는 일은 라우터 설정을 켜는 것만큼 중요하다. RFC 7115는 운영 시 고려할 사항을 다룬다.

기록 자체도 권력이 행사되는 지점이다

일반적으로 사용하는 RPKI 신뢰 계층은 자원 할당 관계를 따르며, 지역 인터넷 등록기관들이 그 뿌리에 있다. 따라서 검증은 건전한 수학에만 의존하지 않는다. 기록을 제공하는 인증 기관과 발행 시스템에도 의존한다.

기록을 바꾸거나 철회하면 검증 결과가 달라질 수 있다. 이것이 곧바로 인터넷 전체의 중단을 뜻하는 것은 아니다. 영향은 다른 가용한 승인과 사업자의 라우팅 정책에 달려 있다. RFC 8211은 인증 기관과 저장소 관리자의 불리한 조치 및 오류를 살펴본다. 보안 메커니즘은 한 위험을 줄이면서도 주의 깊게 살펴볼 만한 의존 관계를 만들 수 있다.

루헝의 주장: 네트워크를 보호하고 문지기의 권한을 제한하라

노트 28, 등록기관이 집행자가 되어서는 안 되는 이유에서 루헝은 분명한 경계를 긋는다. 주소록을 유지하는 일이 이용자를 처벌할 권한으로 바뀌어서는 안 된다는 것이다. 그가 반대하는 것은 관리자가 주장하는 권한이지, 정확한 기록의 필요성이 아니다. 스스로 구성원을 정한 소수 집단이 조정 서비스를 운영한다는 이유만으로 여러 대륙의 네트워크를 지배할 권한까지 위임받는 것은 아니다.

노트 64는 그가 제안하는 대안을 구체화한다. 공유 규칙은 유일성과 보안에 필요한 최소한만 다루고, 참여자 스스로 검증할 수 있는 증거를 제공해야 한다. 기록과 증명은 옮길 수 있어야 한다. 사업자는 네트워크 정체성을 포기하지 않고 서비스 제공자를 바꿀 수 있어야 한다. 향후 변경은 영구적인 행정 통제가 아니라 유용성을 통해 채택을 얻어야 한다.

이는 조정 체계를 다시 세우는 방향이지, 대안 RPKI 시스템이 이미 보편적으로 구축됐다는 주장이 아니다. 그런 시스템도 호환되는 기록과 신뢰할 수 있는 검증을 유지해야 한다. 어려운 부분은 두 가지를 함께 달성하는 것이다. 허위 주장으로부터 보호하면서, 증거에 대해 권한을 행사하면서도 책임지지 않는 주체로부터도 보호해야 한다.

장애 전에 이 질문이 중요한 이유

네트워크의 고객은 매일 익숙한 주소에 의존한다. 기록이 바뀌거나 사라진 뒤에야 의존 관계를 알아차린다면, 복구는 이미 운영 중인 서비스의 문제가 되어 있다. 루헝의 변화 주장은 여기서 출발한다. 분쟁에서 필요해지기 전에 연속성, 독립적인 검증, 떠날 수 있는 능력을 시스템에 포함하자는 것이다.

비판에서 설계로 이어지는 주장을 살펴보려면 최소한의 공유 규칙, 각자의 결정, 자발적 채택에 관한 루헝의 노트 64를 읽어 보자.