지금까지 두 편에 걸쳐 인터넷 라우팅 보안의 두 축을 살펴봤습니다. BGP 취약성 입문에서는 1989년식 신뢰 기반 설계가 어떤 사고들을 만들어 왔는지 짚었고, RPKI 동작 원리에서는 5개 RIR을 트러스트 앵커로 삼아 ROA·ROV·RTR로 출발지를 검증하는 체계를 분해했습니다.
그런데 RPKI 글을 읽으면서 어디서 본 듯한 구조라는 느낌을 받으셨다면 정확히 보신 겁니다. RPKI는 사실 우리가 이미 매일 쓰고 있는 HTTPS의 X.509 PKI를 IP 자원에 그대로 적용한 시스템입니다. 두 시스템은 외형은 다르지만 뼈대가 같습니다. 이번 글은 그 두 세계를 1:1로 매핑해, BGP·RPKI를 더 직관적으로 머릿속에 정리해 보는 비교편입니다.
목차
HTTPS와 X.509 PKI: 30초 요약
웹 브라우저 주소창의 자물쇠 아이콘 뒤에는 다음과 같은 일이 일어나고 있습니다.
- 웹사이트 운영자는 X.509 인증서를 CA(예: DigiCert, Let’s Encrypt)로부터 발급받습니다. 이 인증서에는 “이 도메인은 이 공개키와 짝지어져 있다”는 사실이 CA의 디지털 서명과 함께 박혀 있습니다.
- 브라우저는 자체적으로 신뢰하는 Root CA 목록(트러스트 앵커)을 OS·브라우저에 내장하고 있습니다.
- HTTPS 접속 시점에 브라우저는 서버가 보내온 인증서 체인을 Root CA까지 거슬러 올라가며 서명을 검증하고, 폐기 여부를 CRL 또는 OCSP로 확인합니다.
- 검증을 통과하면 자물쇠가 닫힌 상태로 표시되고, TLS 핸드셰이크가 이어집니다. 실패하면 빨간 경고 화면이 뜹니다.
요컨대 X.509 PKI는 “도메인이 진짜 그 회사 것이라는 보증을 CA가 서명으로 증명해 주는 체계”입니다.
BGP와 RPKI: 30초 요약
인터넷 라우팅에서는 다음과 같은 일이 일어납니다.
- 네트워크 운영자(AS 보유자)는 자기 IP 대역과 ASN에 대한 ROA를 RIR(예: APNIC, KRNIC) 시스템을 통해 발행합니다. ROA에는 “이 prefix는 이 ASN이 광고할 수 있다”는 사실이 RIR의 서명과 함께 박혀 있습니다.
- 전 세계 RPKI 검증기는 자체적으로 신뢰하는 5개 RIR 트러스트 앵커를 출발점으로 가지고, 그 아래 인증서 체인을 따라 ROA를 검증합니다.
- BGP 라우터는 광고가 들어올 때마다 검증기가 RTR로 공급한 VRP 목록과 대조하고, ROA와 일치하지 않는 광고는 Invalid로 폐기합니다.
- ROA가 없는 광고는 Unknown으로 분류되어 관행상 통과시킵니다(아직 RPKI 보급률이 100%가 아니므로).
요컨대 RPKI는 “IP 대역이 진짜 그 AS 것이라는 보증을 RIR이 서명으로 증명해 주는 체계”입니다. 한 단어만 바꿨을 뿐인데 X.509 PKI 설명과 거의 똑같지 않으신가요?
1:1 매핑 비교표
두 세계의 구성요소를 나란히 놓아 보면 다음과 같습니다.
| 역할 | HTTPS / X.509 PKI | BGP / RPKI |
|---|---|---|
| 보호 대상 자원 | 도메인 이름 (example.com) | IP prefix + ASN (192.0.2.0/24, AS65001) |
| 클레임 주체 | 웹사이트 운영자 | 네트워크 운영자(AS 보유자) |
| 클레임 객체 | X.509 TLS 인증서 | ROA (Route Origin Authorization) |
| 클레임 내용 | “이 도메인 = 이 공개키” | “이 prefix = 이 ASN” |
| 발급 기관 | 상용 CA (DigiCert, Sectigo) 또는 Let’s Encrypt | RIR (APNIC, ARIN, RIPE NCC, LACNIC, AFRINIC) |
| 트러스트 앵커 | 브라우저·OS의 Root CA 번들 (수백 개) | 5개 RIR Trust Anchor |
| 인증서 형식 | X.509 v3 | X.509 v3 + RFC 3779 자원 확장 |
| 저장소·배포 | 서버가 핸드셰이크 시 직접 송부 | RPKI repository (RSYNC/RRDP) |
| 폐기 정보 | CRL, OCSP | CRL, Manifest 해시 |
| 검증 주체 | 브라우저 (각 클라이언트) | RPKI Validator + 라우터 |
| 검증 시점 | 매 HTTPS 접속의 TLS 핸드셰이크 | BGP 광고 수신 시점 |
| 판정 결과 | Valid / Invalid (경고 페이지) | Valid / Invalid / Unknown |
| 실패 시 동작 | 접속 차단·빨간 경고 | Invalid는 폐기, Unknown은 통과 |
| 사용자 가시성 | 자물쇠 아이콘으로 즉시 확인 | 일반 사용자는 보이지 않음(라우터 내부 동작) |
| 보호 못하는 영역 | 웹앱 자체 취약점, 서버 코드 | AS Path 위변조 (BGPsec/ASPA 영역) |
같은 점: 사실은 같은 X.509 가족이다
RPKI 인증서는 정말로 X.509 v3 인증서입니다. RFC 3779에서 “subjectPublicKey 필드의 일부 확장으로 IP 주소와 ASN 자원 정보를 인증서에 직접 박는 방법”을 정의했고, RPKI는 그 확장을 그대로 사용합니다. 즉 RPKI 인증서를 OpenSSL 같은 일반 X.509 도구로 들여다보면 보통 인증서와 똑같이 파싱됩니다. 다만 일반 도구는 RFC 3779 확장을 모르기 때문에 “Subject가 누구냐”가 아닌 “이 인증서가 어떤 IP 자원을 보장하느냐”를 해석하지 못할 뿐입니다.
이 사실이 의미하는 바는 큽니다. RPKI는 새로 발명된 암호 체계가 아니라, 인터넷이 25년 넘게 검증해 온 X.509 PKI의 운영 노하우·도구·신뢰 모델을 그대로 끌어다 쓴다는 뜻입니다. 그래서 도입 비용이 상대적으로 낮고, 여러 RIR이 빠르게 인프라를 구축할 수 있었습니다.
다른 점: 검증 주체와 시점, 그리고 Unknown
그럼에도 두 시스템에는 명확한 차이가 있습니다. 가장 큰 세 가지를 짚어 봅니다.
1. 검증을 누가, 언제 하는가
HTTPS는 최종 사용자의 브라우저가 매 접속 때마다 검증을 수행합니다. 사용자가 example.com에 접속하는 그 순간, 브라우저가 인증서를 받아 Root CA까지 거슬러 올라가 서명을 확인하는 것이죠. 검증과 사용 시점이 같은 컴퓨터에서 동시에 일어납니다.
RPKI는 다릅니다. RPKI Validator라는 별도 시스템이 미리 전 세계 저장소를 내려받아 검증을 끝내 놓고, 그 결과를 RTR 프로토콜로 라우터에 공급합니다. 라우터는 BGP 광고가 들어올 때 메모리 안의 VRP 테이블만 조회합니다. 검증의 무거운 일은 미리 분리되어 있고, 라우터는 가벼운 lookup만 합니다. 라우터가 핸드셰이크마다 암호 연산을 하기엔 트래픽이 너무 많기 때문입니다.
2. Unknown을 어떻게 다루는가
HTTPS에서는 인증서가 없거나 신뢰할 수 없으면 사실상 접속이 막힙니다. 브라우저가 빨간 경고 화면을 띄우고 사용자가 일부러 “위험을 감수하고 진입”을 눌러야 합니다. “기본은 거부” 정책입니다.
RPKI는 반대입니다. ROA가 없는 prefix는 Unknown으로 분류되어 관행상 통과시킵니다. 이유는 단순합니다. 2025년 시점에도 전 세계 IPv4 prefix 중 ROA가 있는 비율은 50%를 갓 넘었고, ROA가 없다고 거부하면 인터넷의 절반이 끊겨 버립니다. 그래서 ROV의 표준 정책은 “Invalid는 막고, Unknown은 통과”입니다. 보급률이 충분히 높아질 때까지의 과도기적 타협입니다.
3. 사용자에게 보이는가
HTTPS의 검증 결과는 자물쇠 아이콘으로 사용자에게 즉시 보입니다. 클릭하면 인증서 정보까지 들춰볼 수 있죠. RPKI는 라우터 안에서 조용히 동작하기 때문에 일반 사용자에게는 거의 보이지 않습니다. 자기 사이트가 RIPEstat이나 bgp.tools 같은 공개 도구로 ROA 상태를 확인할 수 있는 정도입니다.
비유로 한 번 더: 도메인 인감증명 vs IP 인감증명
한국식 비유를 빌리자면 X.509 인증서는 “도메인 인감증명서”이고 ROA는 “IP 인감증명서”입니다.
- 도메인 인감증명서: “example.com이 진짜 이 회사의 것이고, 이 공개키가 그 회사의 도장이라는 사실을 CA가 보증한다.”
- IP 인감증명서: “192.0.2.0/24가 진짜 이 AS의 것이고, 이 AS만이 이 대역을 광고할 수 있다는 사실을 RIR이 보증한다.”
두 인감증명 모두 발급기관의 서명이 핵심이고, 발급기관의 권위는 더 위 기관(브라우저 Root CA 번들 / 5개 RIR)이 보증합니다. 위조하려면 결국 최상위 트러스트 앵커의 비밀키를 손에 넣어야 하는데, 이건 사실상 불가능합니다.
마무리: 두 시스템이 비슷해 보였다면 그건 정상이다
RPKI를 처음 공부할 때 “어디서 본 듯하다”는 느낌이 든다면 그 직감이 맞습니다. RPKI는 X.509 PKI의 운영 노하우와 신뢰 모델을 IP 자원에 이식한 체계입니다. 그래서 X.509를 이해하고 있으면 RPKI는 거의 동일한 사고 흐름으로 따라갈 수 있습니다.
차이는 본질이 아니라 적용 영역의 특수성에서 옵니다. 라우터는 매 광고마다 암호 연산을 할 수 없으니 검증을 분리했고(RTR), 인터넷 전체가 RPKI를 채택하지 않은 상태이니 Unknown은 통과시킵니다. 이런 적응이 RPKI의 디자인 결정을 만든 것이지, 암호학적 뼈대 자체가 다른 것은 아닙니다.
다음 글에서는 RPKI가 막지 못하는 마지막 빈자리, 즉 AS Path 위변조를 다루는 BGPsec과 ASPA를 살펴보겠습니다. 이 둘이 왜 RPKI만큼 빠르게 보급되지 않고 있는지, 그 기술적·정치적 이유까지 함께 짚어볼 예정입니다.