BGP 출발지(Origin)를 검증하는 RPKI는 무엇이며 어떻게 동작할까?

지난 글 “BGP는 무엇이고, 어디서 왜 취약한걸까?”에서 우리는 인터넷을 떠받치고 있는 라우팅 프로토콜 BGP가 1989년식 신뢰 모델 위에서 동작한다는 사실을 짚었습니다. 이웃 AS가 “이 IP 대역은 내 것입니다”라고 말하면 그것을 그대로 믿어버리는, 외교 통신에 가까운 구조 말입니다.

그 글의 마지막 부분에서 “RPKI가 출발지를 검증해 준다”고 짧게 언급했습니다. 이번 글은 바로 그 RPKI(Resource Public Key Infrastructure)를 정면에서 분해해 보겠습니다. 어떤 객체로 구성되어 있고, 어떻게 신뢰가 만들어지며, 라우터는 어느 시점에 어떤 정보를 받는지, 그리고 RPKI가 막을 수 있는 것과 막을 수 없는 것이 무엇인지를 차근차근 살펴봅니다.

RPKI는 결국 “IP 주소용 X.509 PKI”다

RPKI를 한 줄로 요약하면 “인터넷 자원(IP 주소·AS 번호)에 대한 공개키 기반 인증 체계”입니다. 우리가 HTTPS에서 사용하는 X.509 인증서가 도메인 소유권을 증명하듯, RPKI 인증서는 “이 조직이 이 IP 대역과 이 ASN을 정당하게 사용할 권한이 있다”는 사실을 암호학적으로 증명합니다.

실제로 RPKI는 X.509v3 인증서 표준에 RFC 3779의 자원 확장(Resource Extension)을 얹은 구조입니다. 즉 인증서 안에 “이 인증서가 보장하는 IP prefix 목록과 ASN 범위”가 명시적으로 포함됩니다. 이 인증서를 가진 주체만이 자기 자원에 대한 ROA를 발행할 수 있고, 그 ROA는 다시 BGP 광고를 검증하는 근거가 됩니다.

신뢰 체인: 5개의 RIR이 시작점이다

RPKI의 신뢰는 지역 인터넷 등록기관(RIR, Regional Internet Registry)에서 시작됩니다. 전 세계는 5개의 RIR로 나뉘어 있고, 각각이 자신의 지역에 IP 자원을 분배합니다.

RIR	관할 지역
APNIC	아시아·태평양 (한국 포함)
ARIN	북미
RIPE NCC	유럽·중동·중앙아시아
LACNIC	라틴아메리카·카리브해
AFRINIC	아프리카

이 5개 RIR이 각자 트러스트 앵커(Trust Anchor) 역할을 합니다. 어떤 RPKI 검증기든 이 5개의 공개키를 미리 신뢰의 출발점으로 가지고 있고, 그 아래로 인증서 체인이 뻗어 나갑니다.

한국의 경우 APNIC 아래에 KRNIC(한국인터넷정보센터, KISA 산하)이 NIR(National Internet Registry)로 존재합니다. KT·LG U+ 같은 ISP나 자체 ASN을 보유한 기업은 KRNIC을 통해 ROA를 발행합니다. 즉 신뢰 체인은 다음과 같이 이어집니다.

RIR(APNIC) → NIR(KRNIC) → LIR(예: KT) → End-Entity 인증서 → ROA

각 단계의 인증서는 상위 인증기관의 비밀키로 서명되어 있고, 검증기는 가장 위의 RIR 트러스트 앵커까지 거꾸로 따라 올라가며 서명을 확인합니다. 어느 한 고리라도 깨지면 그 ROA는 무효로 처리됩니다.

RPKI의 4가지 핵심 객체

실제로 RPKI 저장소에 게시되는 파일은 크게 네 종류입니다.

객체	역할
자원 인증서 (Resource Certificate, .cer)	특정 조직이 보유한 IP prefix·ASN 범위를 명시한 X.509 인증서. 상위 CA가 서명한다.
ROA (Route Origin Authorization, .roa)	“이 prefix는 이 ASN이 광고할 수 있다”는 선언. Origin AS, IP Prefix, MaxLength 세 항목을 포함한다.
매니페스트 (Manifest, .mft)	저장소 디렉터리 안의 모든 파일 이름과 해시 목록. 누가 객체를 임의로 추가·삭제·교체했는지 탐지한다.
CRL (Certificate Revocation List, .crl)	폐기된 인증서 일련번호 목록. 키 유출이나 잘못 발급된 인증서를 무력화한다.

이 네 객체가 모여 하나의 RPKI 저장소(repository)를 구성하고, 검증기는 이 저장소를 RSYNC 또는 RRDP(RPKI Repository Delta Protocol) 방식으로 주기적으로 내려받습니다.

ROA 발행: Hosted 방식과 Delegated 방식

네트워크 운영자가 자기 prefix에 대한 ROA를 만드는 방법은 두 가지입니다.

Hosted 모델

가장 간단하고 흔한 방식입니다. ISP는 직접 CA 서버를 운영하지 않고, 상위 RIR(또는 NIR)이 제공하는 웹 포털에 로그인해 자기 prefix와 ASN을 입력하면 RIR의 시스템이 자동으로 ROA를 생성·서명·게시합니다. 비밀키는 RIR이 보관합니다.

한국의 KISA/KRNIC도 현재는 Hosted 모델만 지원합니다. KISA 회원기관은 KRNIC 포털을 통해 자기 IP 대역과 사용 ASN을 등록하면 됩니다. KRNIC의 IP/AS 회원기관(관리대행자, 독립사용자)에 한해 제공됩니다.

KRNIC 바로가기

Delegated 모델

큰 ISP나 대형 클라우드 사업자는 자체 CA 서버와 저장소를 직접 운영하기도 합니다. 비밀키와 인증서 발급 권한을 자기 인프라에 두는 방식이라 통제권이 강한 대신, RPKI 인프라 운영의 책임도 모두 떠안아야 합니다. RIPE NCC·APNIC 등은 이 방식도 지원합니다.

ROV 검증 흐름: Validator와 RTR 프로토콜

ROA가 저장소에 게시되었다고 해서 라우터가 자동으로 알게 되는 것은 아닙니다. 사이에 RPKI 검증기(Validator)가 끼어 있어야 합니다.

저장소 동기화: 검증기는 5개 RIR의 트러스트 앵커에서 시작해 전 세계 RPKI 저장소를 내려받습니다. 대표 오픈소스 검증기로는 NLnet Labs의 Routinator, Cloudflare의 OctoRPKI, RIPE NCC의 RPKI Validator 3 등이 있습니다.
암호학적 검증: 모든 인증서 체인의 서명을 트러스트 앵커까지 따라 올라가며 확인합니다. 매니페스트 해시 일치, CRL 폐기 여부, 만료 시점도 함께 점검합니다.
VRP 생성: 검증을 통과한 ROA들로부터 VRP(Validated ROA Payload)의 집합을 만듭니다. 각 VRP는 (ASN, Prefix, MaxLength) 형태의 단순한 튜플입니다.
RTR로 라우터에 공급: 검증기는 RTR(RPKI to Router) 프로토콜로 라우터에게 VRP 목록을 제공합니다. 라우터는 BGP 광고가 들어올 때마다 메모리 안의 VRP와 대조합니다.

이 구조 덕분에 라우터 자신은 무거운 암호 연산을 하지 않습니다. 라우터가 보는 것은 미리 검증되어 단순화된 VRP 테이블뿐이고, 검증 부담은 검증기가 모두 흡수합니다.

Valid · Invalid · Unknown: 세 가지 판정 결과

BGP 광고가 들어왔을 때 라우터가 VRP와 대조해 내리는 판정은 다음 셋 중 하나입니다.

결과	의미	일반적 처리
Valid	광고된 prefix와 origin AS가 ROA와 정확히 일치	정상 수락, 우선순위 가산
Invalid	해당 prefix에 ROA가 있지만 origin AS가 다르거나, prefix 길이가 MaxLength를 초과	폐기 또는 매우 낮은 우선순위 부여
Unknown (Not Found)	해당 prefix에 대한 ROA가 아직 발행되지 않음	RPKI 미적용 광고와 동일하게 수락

중요한 포인트는 Unknown은 거부 사유가 아니라는 점입니다. RPKI 보급률이 100%가 아닌 상태에서 ROA가 없는 prefix를 일괄 거부하면 인터넷의 절반이 끊겨 버립니다. 따라서 ROV는 “Invalid는 막고, Unknown은 통과”가 표준 정책입니다.

MaxLength 함정과 ROA 작성의 모범 사례

ROA에 들어가는 세 번째 필드인 MaxLength가 함정이 되는 경우가 있습니다. 예를 들어 어떤 조직이 192.0.2.0/22를 보유하면서 ROA에 MaxLength=24로 적었다고 합시다. 이 ROA는 “이 ASN이 /22부터 /24까지의 어떤 더 구체적인 prefix를 광고해도 모두 valid”라고 선언하는 셈입니다.

문제는 그 조직이 실제로는 /24를 광고하지 않을 때입니다. 공격자가 같은 origin AS를 위장해 192.0.2.128/25나 192.0.2.128/24를 광고하더라도 ROA는 valid로 판정합니다(MaxLength 범위 안이므로). 정상 트래픽보다 더 구체적인 광고이므로 라우터는 공격자 경로를 우선 선택합니다.

이 현상이 “Forged-Origin Hijack”이며, MANRS와 NIST는 이를 막기 위해 다음 원칙을 권장합니다.

MaxLength는 실제로 광고하는 가장 긴 prefix 길이로만 설정한다. 즉 /22만 광고한다면 MaxLength도 /22로 두고, /24도 광고한다면 /22·/24 두 ROA를 따로 발행한다.
“Minimal ROA” 원칙이라고도 불리며, RFC 9319(The Use of maxLength in the RPKI, 2022)에 정식 가이드라인으로 수록되어 있다.

RPKI가 막지 못하는 것: AS Path 위변조

RPKI를 잘 적용했다고 해서 BGP 보안 문제가 모두 해결되는 것은 아닙니다. RPKI는 오직 출발지(Origin)만 검증합니다. BGP 광고가 어떤 AS들을 거쳐 왔는지, 그 AS Path가 진짜인지는 RPKI의 검증 범위 밖입니다.

예를 들어 공격자가 자기 ASN을 origin으로 두지 않고, AS Path 끝에 정상 ASN을 얹어 광고하면 RPKI는 valid로 판정합니다. 출발지만 보면 합법적이기 때문입니다. 이런 공격을 막으려면 path 자체에 서명을 붙이거나 path 정합성을 검증하는 별도 메커니즘이 필요합니다.

BGPsec (RFC 8205): 각 AS가 자기 단계의 AS Path 추가에 디지털 서명을 붙여, 경로 전체가 위조 없이 전파되었음을 보장. 라우터 부담이 매우 커서 도입은 더디다.
ASPA (Autonomous System Provider Authorization, IETF 표준화 진행 중): “이 AS의 정당한 업스트림은 이 AS들뿐”이라고 선언해 비현실적인 경로를 걸러내는 가벼운 보완책. 2024–2025년 들어 도입 사례가 늘고 있다.

즉 RPKI는 “출발지 검증”이라는 한 축을 책임지고, BGPsec·ASPA가 “경로 검증”이라는 다른 축을 점진적으로 메우는 분담 구조입니다.

한국의 RPKI 도입 현황: 0.27%라는 숫자

전 세계 IPv4 prefix의 ROA 보호율이 2024년 5월 기준 50%를 넘어선 가운데, 한국의 상황은 상당히 뒤처져 있습니다. 2023년 OECD 자료 기준 한국의 RPKI 적용률은 0.27%로 OECD 회원국 중 최하위를 기록했습니다.

이유는 복합적입니다.

국내 ISP들이 라우팅 사고 경험이 적어 RPKI 필요성을 체감하지 못함
기존 라우터·BGP 설정에 변경을 가하는 데 따른 장애 우려
KISA의 RPKI 서비스가 회원기관에만 한정되어 있고, 홍보·교육이 부족함

그래도 변화는 시작되었습니다. KREONET(국가과학기술연구망)은 KISTI와 KISA 협력으로 RPKI를 전면 도입한 사례이며, KISA는 인식 제고와 기술 교육 채널을 늘려가고 있습니다. 미국 FCC가 2025년 1월부터 ISP에 RPKI 적용을 권고한 흐름과 맞물려, 한국도 향후 몇 년 내 도입률이 의미 있게 올라갈 것이라는 전망이 우세합니다.

KREONET(국가과학기술연구망) 바로가기

마무리

RPKI는 거창한 새 기술이 아니라, 우리가 이미 30년 가까이 써 온 X.509 PKI를 IP 자원에 그대로 적용한 체계입니다. 5개 RIR이 트러스트 앵커가 되고, 그 아래로 자원 인증서가 분기하며, 최종 단계에서 ROA가 “이 prefix는 이 ASN이 광고할 수 있다”고 선언합니다. 검증기는 RTR로 라우터에 그 정보를 주입하고, 라우터는 valid가 아닌 광고를 거부합니다.

완벽하지는 않습니다. AS Path 위변조는 BGPsec·ASPA의 영역이고, MaxLength를 헐겁게 잡으면 forged-origin 공격에 그대로 노출됩니다. 그러나 RPKI는 BGP 보안의 가장 큰 출입문이며, 2025년 시점에서는 사실상 인터넷 라우팅 보안의 기본값입니다. 자기 prefix가 ROA로 보호되고 있는지를 확인하는 것은 더 이상 선택이 아닙니다.

다음 글에서는 BGPsec와 ASPA가 어떻게 RPKI의 빈자리를 메우려 하는지, 그리고 왜 BGPsec은 10년 가까운 표준화에도 불구하고 거의 배포되지 못했는지를 살펴보겠습니다.

Post Views: 0