RPKI(Resource Public Key Infrastructure, 자원 공개키 기반구조)

1. 개요

RPKI(Resource Public Key Infrastructure)란 IP 주소 블록(prefix)과 자율시스템 번호(ASN) 같은 인터넷 번호자원의 소유·위임 관계를 X.509 인증서 체계로 암호학적으로 증명하고, 이를 근거로 "어떤 AS가 어떤 prefix를 광고할 권한이 있는가"를 검증 가능하게 만드는 공개키 기반구조다. 그 위에서 라우터가 BGP 경로의 출처를 검사하는 절차를 ROV(Route Origin Validation, 경로 출처 검증)라 하며, RPKI는 이 ROV의 신뢰 근거를 제공하는 뼈대에 해당한다.

RPKI가 등장한 배경에는 인터넷 도메인 간 라우팅 프로토콜인 BGP가 태생적으로 '신뢰(trust-by-default)'에 기대고 있다는 구조적 약점이 있다. BGP는 각 AS가 "나는 이 prefix를 가지고 있고, 이 경로로 도달할 수 있다"고 서로에게 알리면 이웃이 그 말을 별도 검증 없이 받아들여 전 세계로 전파하는 방식으로 동작한다. 1980년대 말 수백 개 기관이 서로를 아는 소규모 네트워크였을 때는 이 낙관적 신뢰가 충분히 작동했지만, 오늘날 7만 개가 넘는 AS가 익명적으로 상호접속하는 환경에서는 한 사업자의 오설정이나 악의적 광고 하나가 경로 하이재킹(prefix hijacking)으로 번져 특정 서비스로 가는 트래픽을 통째로 엉뚱한 곳으로 빨아들이는 사고를 낳는다. 2008년 파키스탄텔레콤이 유튜브 prefix를 잘못 광고해 전 세계에서 유튜브가 수 시간 마비된 사건, 2018년 공격자가 아마존 Route53 DNS prefix를 가로채 암호화폐 지갑 MyEtherWallet 이용자의 자금을 탈취한 사건은 이 "검증 없는 전파"가 왜 위험한지를 상징적으로 보여 준다.

이런 위협에 대응하려면 라우터가 경로 광고를 받을 때 "이 광고의 출처 AS가 해당 prefix에 대한 광고 권한을 실제로 가졌는가"를 암호학적으로 확인할 수 있어야 한다. 그런데 권한의 뿌리는 결국 번호자원을 분배하는 IANA→RIR(지역 인터넷 레지스트리)→ISP/기관으로 내려오는 위임 계층에 있으므로, 이 위임 관계를 그대로 인증서 체계로 옮겨 "자원을 가진 자만이 서명할 수 있는" 구조를 만들면 된다. RPKI는 바로 이 발상에서 출발해, 번호자원의 할당 계층을 공개키 인증서의 신뢰 계층으로 사상(mapping)한 PKI다. IETF SIDR/SIDROPS 워킹그룹이 RFC 6480(아키텍처)을 중심으로 표준화했고, 경로 권한을 선언하는 ROA(Route Origin Authorization) 프로파일은 RFC 6482에서 정의된 뒤 RFC 9582로 갱신되었으며, 라우터의 출처 검증 절차는 RFC 6811, 라우터-검증기 간 전달은 RFC 8210(RPKI-to-Router)로 규정된다.

RPKI의 필요성은 세 축에서 분명해진다. 첫째는 출처의 진위 확인으로, "말로만 하는 소유 주장"을 "서명으로 증명되는 권한"으로 바꾼다. 둘째는 오설정·사고의 자동 차단으로, 악의가 없는 단순 오타형 광고(fat-finger)까지 걸러 내 라우팅 사고의 상당수를 사전에 막는다. 셋째는 생태계적 신뢰 회복으로, 개별 사업자의 선의에만 기대던 라우팅 보안을 검증 가능한 공통 기반 위에 올려 둔다. 다만 뒤에서 보듯 RPKI는 '출처(origin)'만 검증할 뿐 '전체 경로(AS-PATH)'를 보증하지는 못하므로, 그 경계를 정확히 아는 것이 기술사 관점에서 특히 중요하다.

RPKI를 다른 보안 기술과 구별 짓는 본질적 특징은 자원 기반 신뢰, 계층형 위임, 그리고 검증과 집행의 분리로 요약된다. 신원이 아니라 번호자원의 소유를 증명한다는 점에서 일반 PKI와 다르고, 신뢰가 IANA→RIR→사업자의 자원 위임 경로를 따라 흐른다는 점에서 수평적 신뢰망(web of trust)과도 다르며, 무거운 검증은 RP가 전담하고 라우터는 가벼운 조회만 한다는 점에서 라우터 성능 제약을 우회한다. 이 세 특징이 뒤에서 다룰 "출처만 보증한다"는 한계와 "신뢰 집중"이라는 거버넌스 부담을 동시에 설명하는 열쇠가 된다.

2. RPKI 신뢰 구조와 구성요소

RPKI를 이해하는 핵심은 "번호자원의 위임 계층을 인증서의 신뢰 계층으로 그대로 옮겼다"는 구조적 대응이다. 즉 어떤 기관이 특정 prefix를 광고할 권한이 있다는 사실은, 그 prefix가 RIR→상위 사업자→해당 기관으로 서명되어 내려온 인증서 경로로 증명된다. 전체 체계는 크게 "권한을 선언하는 쪽(자원 보유자가 ROA를 발급·게시)"과 "그 선언을 소비하는 쪽(RP가 검증하고 라우터가 집행)"으로 나뉘며, 둘 사이를 저장소와 RPKI-RTR 프로토콜이 잇는다. 아래 전체 구조도는 자원 인증서 계층(위)과 그 위에서 라우터가 검증 재료를 공급받는 경로(아래)를 함께 보여 준다.

flowchart TB
  subgraph TRUST["RPKI 신뢰 계층(자원 인증서)"]
    TA["트러스트 앵커: 5개 RIR(APNIC/RIPE/ARIN/LACNIC/AFRINIC)"]
    ISP["ISP·기관 CA(위임받은 자원)"]
    ROA["ROA: (prefix, maxLength, 출처 ASN) 전자서명"]
    TA --> ISP
    ISP --> ROA
  end
  subgraph VAL["검증·전파 체계"]
    PUB["RPKI 저장소(repository, RRDP/rsync)"]
    RP["RP 검증기(Routinator·rpki-client·FORT)"]
    VRP["VRP(검증된 ROA 목록)"]
    RTR["RPKI-RTR 프로토콜(RFC 8210)"]
    RTR2["BGP 라우터(ROV 수행)"]
    ROA -.게시.-> PUB
    PUB --> RP
    RP --> VRP
    VRP --> RTR
    RTR --> RTR2
  end

가. 자원 인증서 계층과 트러스트 앵커

RPKI 신뢰의 뿌리는 5개 RIR(APNIC·RIPE NCC·ARIN·LACNIC·AFRINIC)이 운영하는 트러스트 앵커(Trust Anchor)다. 각 RIR은 자신이 IANA로부터 위임받은 주소·AS 자원 전체를 포괄하는 최상위 인증서를 발급하고, 그 밑으로 자원을 할당받은 ISP·NIR(국가 레지스트리)·대형 기관에게 RFC 3779 확장(인증서에 IP·ASN 자원을 기재)을 담은 하위 인증서를 서명해 내려보낸다. 여기서 핵심은 인증서가 '신원'이 아니라 '자원'을 증명한다는 점이다. 일반 웹 PKI의 인증서가 "이 공개키는 example.com의 것"임을 보증한다면, RPKI 인증서는 "이 공개키의 소유자는 192.0.2.0/24와 AS64500을 쓸 권한이 있다"를 보증한다. 그래서 RPKI를 자원 PKI라 부른다.

이 계층형 구조 덕분에 권한의 위조가 어렵다. 어떤 기관이 특정 prefix에 대한 ROA를 만들려면, 그 prefix가 자기 인증서의 자원 목록에 포함되어 있어야 하고, 그 인증서는 다시 상위 RIR까지 서명 체인으로 연결되어야 한다. 중간에 하나라도 자원 범위를 벗어나거나 서명이 끊기면 검증기가 경로 전체를 무효로 판정한다. 다만 이 구조는 뒤의 심화에서 다루듯 RIR이라는 소수 주체에 신뢰가 집중되는 거버넌스적 부담도 동시에 안고 있다.

인증서 계층은 또한 자원의 재위임(sub-allocation)을 그대로 표현할 수 있다는 장점이 있다. 예컨대 RIR이 대형 통신사에게 /16을 할당하고, 그 통신사가 다시 산하 기관에 /20을 재할당하면, 인증서도 동일한 포함관계로 한 단계 더 서명되어 내려간다. 이렇게 "자원이 흐르는 경로"와 "신뢰가 흐르는 경로"가 일치하도록 설계했기 때문에, RPKI는 별도의 신원 등록기관 없이도 번호자원의 분배 체계 그 자체를 보안의 근거로 재사용한다. 반대로 상위 인증서가 만료·취소되면 그 아래 모든 하위 객체가 한꺼번에 무효가 되므로, 인증서의 갱신 주기 관리와 만료 전 재발급(roll-over)이 운영상 매우 중요한 과제가 된다.

나. ROA(Route Origin Authorization)

ROA는 "어떤 출처 AS가 어떤 prefix를 광고해도 좋다"는 권한 선언을 전자서명한 객체다. 하나의 ROA는 (출처 ASN, 하나 이상의 prefix, 각 prefix의 maxLength) 세 요소로 구성된다. 예를 들어 어떤 기관이 203.0.113.0/24를 AS64500으로 광고한다면, 그 기관은 (AS64500, 203.0.113.0/24, maxLength 24)라는 ROA를 발급한다. 여기서 maxLength는 "이 prefix를 몇 비트까지 잘게 쪼개(subnet) 광고하는 것을 허용하는가"를 뜻한다. maxLength를 24로 두면 정확히 /24만 유효하지만, 가령 /22 prefix에 maxLength 24를 주면 /22~/24의 모든 하위 prefix 광고가 유효로 인정된다. 뒤에서 보듯 이 maxLength를 지나치게 느슨하게 설정하는 것이 오히려 공격 표면을 넓히는 전형적 실수다.

ROA의 발급 방식은 운영 책임의 경계에 따라 호스팅형(hosted)과 위임형(delegated)으로 나뉜다. 호스팅형은 RIR·NIR이 제공하는 포털에서 자원 보유자가 몇 번의 클릭으로 ROA를 만들고, 서명 키와 저장소 운영은 RIR이 대신 떠맡는 방식이다. 진입 장벽이 낮아 대다수 중소 사업자가 택하며, 대신 키 통제권이 RIR에 있다는 점을 감수한다. 위임형은 기관이 직접 CA와 저장소를 운영해 서명 키를 자신이 통제하는 방식으로, 통제력은 크지만 그만큼 인증서 갱신·저장소 가용성·키 보호를 스스로 책임져야 한다. 실무에서는 "통제력 대 운영부담"이라는 전형적 트레이드오프 아래, 조직 규모와 보안 요구에 맞춰 두 방식을 선택한다.

다. RP(Relying Party) 검증기와 VRP

ROA는 RIR·사업자가 운영하는 분산 저장소(repository)에 게시되고, 이를 수집·검증하는 주체가 RP(Relying Party) 소프트웨어다. Routinator(NLnet Labs)·rpki-client(OpenBSD)·FORT·OctoRPKI 같은 검증기가 대표적이다. RP는 트러스트 앵커에서 출발해 저장소의 모든 인증서·ROA를 내려받아 서명 체인과 자원 포함관계를 검증한 뒤, 유효한 것만 추려 VRP(Validated ROA Payload, 검증된 ROA 목록)를 산출한다. VRP는 결국 "(출처 ASN, prefix, maxLength)" 튜플의 집합이며, 라우터가 실제 검증에 쓰는 재료가 된다. 저장소 동기화는 과거 rsync 중심에서 변경분만 효율적으로 받는 RRDP(RFC 8182, HTTPS 기반)로 무게중심이 옮겨 가 가용성과 확장성이 개선되었다.

RP 운영에서 간과하기 쉬운 지점은 RP 자신이 라우팅 보안의 단일 장애점(SPOF)이 될 수 있다는 것이다. RP가 특정 RIR 저장소에 접근하지 못하거나 검증 과정에서 멈추면, 해당 범위의 VRP가 통째로 빠져 정상 경로가 갑자기 NotFound·Invalid로 뒤바뀔 수 있다. 그래서 대형 사업자는 지역·구현을 달리한 RP를 복수로 구성하고, 저장소 접근 실패 시 과거 VRP를 일정 시간 유지하는 등 그레이스풀 디그레이데이션(graceful degradation) 정책을 둔다. 또한 RP는 서명이 잘못되었거나 자원 범위를 벗어난 객체를 조용히 걸러 내므로, 운영자는 RP 로그로 "왜 특정 ROA가 VRP에 반영되지 않았는지"를 추적할 수 있어야 한다.

라. RPKI-RTR 프로토콜과 라우터

마지막으로 RP가 만든 VRP는 RPKI-to-Router 프로토콜(RFC 8210)을 통해 BGP 라우터에게 전달된다. 라우터는 무거운 암호 연산(서명 검증)을 직접 하지 않고, 이미 검증을 마친 RP로부터 VRP 집합만 받아 가벼운 조회(lookup) 형태로 ROV를 수행한다. 이 역할 분리가 중요한데, 수십만 개 ROA의 서명 검증을 라우터가 매번 하는 것은 비현실적이므로, 연산 집약적 검증은 RP가 전담하고 라우터는 그 결과만 소비하도록 설계한 것이다. 이렇게 "검증(RP)과 집행(라우터)"을 분리한 것이 RPKI 운영 아키텍처의 요체다.

RPKI-RTR 세션은 RP(서버)와 라우터(클라이언트) 사이에 상태를 유지하며, 처음에는 전체 VRP를 내려받고 이후에는 변경분(delta)만 증분 전송해 라우터의 메모리와 세션 부하를 줄인다. 또 세션 자체의 무결성·기밀성을 위해 TCP-AO나 SSH, TLS 같은 보호 채널 위에서 운용하도록 권고되는데, 이는 "검증 결과를 나르는 통로"가 변조되면 ROV 전체가 무력화되기 때문이다. 운영자는 보통 하나의 라우터가 복수의 RP 캐시에 동시 접속하도록 구성해, 한 RP가 다운되어도 다른 RP의 VRP로 ROV를 이어 가도록 이중화한다.

구성요소	역할	대표 구현/표준
트러스트 앵커	신뢰의 뿌리(자원 최상위 인증서)	5개 RIR
자원 인증서	번호자원 위임 증명(RFC 3779)	RFC 6487
ROA	출처 AS의 광고 권한 선언(서명)	RFC 6482 → RFC 9582
RP 검증기	저장소 수집·검증 → VRP 생성	Routinator·rpki-client·FORT
RPKI-RTR	VRP를 라우터에 전달	RFC 8210
BGP 라우터	VRP 기반 ROV·정책 집행	RFC 6811

3. ROV(경로 출처 검증) 동작 절차와 검증 상태

라우터가 이웃으로부터 BGP 경로 광고를 받으면, 광고에 담긴 출처 AS(AS-PATH의 가장 오른쪽 AS)와 prefix를 VRP 집합과 대조해 세 가지 상태 중 하나로 판정한다. 아래 상세 흐름도는 광고 수신부터 정책 결정까지의 과정을 보여 준다.

flowchart TD
  A["BGP 경로 광고 수신(prefix + AS-PATH)"] --> B["광고의 출처 AS·prefix 추출"]
  B --> C{"VRP에 이 prefix를 덮는 항목이 있는가?"}
  C -->|"없음"| D["NotFound(Unknown): ROA 미등록"]
  C -->|"있음"| E{"출처 ASN 일치 & prefix 길이 <= maxLength?"}
  E -->|"예"| F["Valid: 권한 있는 광고"]
  E -->|"아니오"| G["Invalid: 출처 불일치 또는 과도한 분할"]
  D --> H["정책: 보통 수용(차단 시 대량 단절 위험)"]
  F --> I["정책: 수용 + 우선순위 상향 가능"]
  G --> J["정책 권고: drop(폐기)"]

Valid(유효)는 광고의 출처 AS와 prefix가 VRP의 어떤 항목과 정확히 부합하고 prefix 길이도 maxLength 이내인 경우다. Invalid(무효)는 해당 prefix를 덮는 ROA는 존재하지만 출처 AS가 다르거나(권한 없는 AS가 광고) prefix가 maxLength를 넘어 지나치게 잘게 쪼개진 경우로, 하이재킹이 의심되는 상태다. NotFound(또는 Unknown)는 그 prefix에 대한 ROA 자체가 없어 검증할 근거가 없는 상태다.

세 상태 가운데 현실에서 가장 많은 비중을 차지하는 것은 오랫동안 NotFound였다. 전 세계 prefix의 상당수가 아직 ROA를 등록하지 않았기 때문으로, 바로 이 점이 "검증은 하되 섣불리 차단하면 안 되는" 긴장을 만든다. 라우팅은 도달성이 생명이므로, 근거가 없다는 이유만으로 NotFound를 버리면 멀쩡한 목적지로 가는 길이 끊긴다. 그래서 ROV의 실질 효과는 전체 경로를 흑백으로 가르는 것이 아니라, 명백히 권한을 위반한 Invalid만 외과적으로 제거하는 데 있다.

여기서 기술사적으로 중요한 함의는 "Invalid를 어떻게 처리할 것인가"가 곧 보안 효과를 좌우한다는 점이다. 검증만 하고 Invalid 경로를 그대로 수용하면 RPKI는 사실상 '구경'에 불과하다. 실제 방어는 Invalid 경로를 폐기(drop)하는 정책을 라우터에 적용할 때 비로소 발생한다. 반면 NotFound는 아직 ROA를 만들지 않은 세계의 절반 이상을 차지하므로, 이를 무조건 차단하면 정상 트래픽이 대량 단절된다. 그래서 현실 운영은 "Invalid는 버리고, NotFound는 수용하며, Valid는 선호"하는 비대칭 정책으로 수렴한다. 이 때문에 ROA 등록을 늘려 NotFound를 줄이는 일(ROA 커버리지 확대)과, 받은 Invalid를 실제로 버리는 일(ROV 집행)이 서로 다른 두 과제로 나뉘며, 뒤의 통계가 보여 주듯 둘 사이에는 큰 간극이 있다.

운영 현장에서는 Invalid를 곧바로 폐기하기보다 BGP local-preference를 낮춰 후순위로 두는 단계적 전환을 거치기도 한다. 갑작스러운 drop이 오설정으로 인한 대규모 단절을 부를까 우려해, 먼저 로그·알람으로 Invalid를 관찰하며 오탐 여부를 검증하고, 안정되면 비로소 폐기 정책을 켜는 식이다. 이처럼 "검증→관찰→후순위→폐기"의 점진적 적용은 가용성을 지키면서 보안을 높이는 전형적 운영 패턴이다.

4. RPKI의 한계와 보완 기술 — ROV·BGPsec·ASPA 비교

RPKI/ROV의 가장 근본적 한계는 출처(origin)만 검증할 뿐 전체 경로(AS-PATH)의 진위는 보증하지 않는다는 데 있다. 이 차이가 생기는 이유는 ROA가 "누가 이 prefix의 출발점이 될 수 있는가"만 선언하기 때문이다. 따라서 공격자가 정당한 출처 AS를 경로 끝에 그대로 붙여 위조하는 '위조 출처(forged-origin) 하이재킹'이나, 경로를 받은 대로 전달하지 않고 규칙을 어겨 재광고하는 경로 누출(route leak)은 ROV를 그대로 통과한다. 즉 ROV는 "출발지 위조"는 막아도 "중간 경로 조작"은 막지 못한다. 실제로 과도한 maxLength로 하위 prefix 광고를 넓게 허용해 두면, 공격자가 그 범위 안에서 더 긴(more-specific) prefix를 정당한 출처를 달고 광고해 트래픽을 끌어가는 공격이 Valid로 판정될 수 있다 — maxLength를 꼭 필요한 값으로 좁혀야 하는 이유다.

위조 출처 하이재킹의 위험을 구체적 수치로 보면 더 분명하다. 정당한 보유자가 198.51.100.0/22를 AS64500으로 광고하면서 ROA를 (AS64500, 198.51.100.0/22, maxLength 24)로 느슨하게 설정했다고 하자. 공격자는 이 범위 안의 더 긴 prefix인 198.51.100.0/24를 AS-PATH 끝에 정당한 AS64500을 그대로 붙여 광고할 수 있다. 라우터는 더 긴 prefix(longest-prefix match)를 우선하므로 공격자의 /24로 트래픽이 쏠리는데, 출처 AS가 AS64500이고 길이 24가 maxLength 이내이므로 ROV 판정은 Valid가 된다. 만약 maxLength를 실제 사용하는 22로만 좁혀 두었다면 길이 24 광고는 maxLength 초과로 곧바로 Invalid가 되어 막혔을 것이다. 이처럼 maxLength 한 줄의 설정이 공격 가능 여부를 가르며, 이것이 "maxLength는 꼭 필요한 최소값으로"라는 운영 원칙의 근거다.

이 공백을 메우기 위한 보완 기술이 BGPsec와 ASPA다. BGPsec(RFC 8205)은 AS-PATH의 각 홉(hop)이 다음 AS로 전달될 때마다 경로를 서명해 전체 경로의 무결성을 암호학적으로 보장하지만, 홉마다 서명·검증을 수행해야 해 라우터의 연산·메모리 부담이 크고 전면 배포가 사실상 정체되어 있다. 반면 ASPA(Autonomous System Provider Authorization)는 "이 AS의 상위(provider)는 누구인가"를 RPKI 객체로 선언하게 해, 경로가 고객-공급자 관계의 정상 형태를 벗어났는지(=경로 누출·일부 경로 조작)를 비교적 가벼운 연산으로, 그리고 부분 배포 상태에서도 효과를 내도록 설계되어 최근 가장 유망한 대안으로 주목받고 있다.

구분	ROV(RPKI 출처검증)	ASPA	BGPsec
검증 대상	출처 AS만	고객-공급자 경로 관계	AS-PATH 전체(홉별 서명)
막는 위협	단순 출처 하이재킹·오설정	경로 누출·일부 경로 조작	경로 위조 전반
연산 부담	낮음(라우터는 조회만)	중간	높음(홉별 서명·검증)
부분 배포 효과	있음	있음(상대적으로 큼)	작음
성숙도	널리 배포 중	표준화·초기 배포 단계	정체

이 비교의 실무적 함의는 분명하다. 어느 하나가 모든 위협을 막는 '은총알'이 아니며, ROV로 출처 위협을 걷어 낸 뒤 ASPA로 경로 누출을 보완하고, 장기적으로 BGPsec의 경로 무결성을 더하는 계층적·단계적 적용이 현실적 전략이라는 것이다.

여기서 부분 배포(partial deployment) 효과라는 개념이 전략 선택을 가른다. BGPsec는 경로상의 모든 AS가 서명에 참여해야 의미가 있어, 전 세계가 동시에 전환하지 않으면 보호 효과가 미미하다 — 이것이 BGPsec 배포가 사실상 멈춘 근본 이유다. 반면 ROV와 ASPA는 일부 AS만 집행해도 그 AS가 받는 하이재킹·누출 경로를 바로 걸러 낼 수 있어, "먼저 도입한 자가 먼저 이득을 보는" 유인이 작동한다. 보안 기술의 성패가 암호 강도만이 아니라 배포 경제성(deployability)에 달려 있음을 RPKI 생태계가 뚜렷이 보여 주는 셈이며, 이는 기술사가 신기술 도입을 설계할 때 반드시 고려해야 할 관점이다.

5. 심화: 배포 현황·실제 사례·국내외 동향

RPKI는 "표준은 갖춰졌으나 배포는 진행 중"인 대표적 사례다. 2026년 중반 기준 전 세계 라우팅 prefix 가운데 약 2/3(약 67%)가 ROA를 보유한 것으로 측정되며, IPv6(약 73%)가 IPv4(약 66%)보다 커버리지가 높다. 그러나 받은 Invalid를 실제로 폐기(ROV 집행)하는 AS의 비중은 측정 방법에 따라 약 12~33% 수준으로 훨씬 낮다. 즉 "권한을 선언해 둔 집(ROA)"은 늘었지만 "문단속을 실제로 하는 집(ROV drop)"은 아직 소수라는 뜻으로, 이 커버리지-집행 간극(coverage–enforcement gap)이 현 단계 라우팅 보안의 핵심 현안이다. 이 수치들은 출처·시점·측정 방법(APNIC Labs, Hurricane Electric 등)에 따라 편차가 크므로 단정보다 경향으로 읽어야 한다.

이 간극이 왜 중요한지는 간단한 산술로 드러난다. 설령 전 세계 prefix의 100%가 ROA를 등록(커버리지 100%)하더라도, 트래픽이 지나는 AS들이 Invalid를 폐기하지 않으면(ROV 집행 0%) 하이재킹 경로는 여전히 전파된다. 반대로 ROA는 아직 적어도, 핵심 트랜짓 AS들이 ROV를 집행하면 그들이 거르는 범위만큼 즉시 보호가 발생한다. 즉 라우팅 보안의 체감 효과는 "ROA를 등록한 집(피해자 측)"과 "Invalid를 버리는 집(전파 경로 측)"의 곱으로 나타나며, 이것이 커버리지·집행 두 지표를 분리 관리해야 하는 이유다.

실제 사례는 RPKI의 효용과 한계를 동시에 보여 준다. 2018년 MyEtherWallet 사건은 ROV가 왜 필요한지를, 2024년 6월 Cloudflare의 공개 DNS(1.1.1.1)가 하이재킹과 경로 누출이 겹쳐 전 세계적으로 접속 장애를 겪은 사건은 ROV만으로는 경로 누출을 막지 못한다는 한계를 각각 드러냈다. 2025년에는 공격자가 RPKI를 깨뜨리는 대신 상위 사업자의 고객 신원확인 절차가 허술한 틈을 사회공학적으로 파고들어 하이재킹 ASN에 트랜짓을 열게 한 사례가 보고되었는데, 이는 암호 기술만으로는 메울 수 없는 운영·프로세스 보안의 중요성을 환기한다. 국내에서도 KISA/KRNIC이 APNIC 산하 국가 레지스트리로서 국내 자원 보유자를 위한 호스팅형 RPKI CA를 제공하고 있으며, 통신사업자의 ROA 등록과 ROV 집행이 점차 확대되는 추세다. 이러한 자율 규범 확산을 뒷받침하는 국제 이니셔티브가 MANRS로, 필터링·출발지 위조 방지·좌표(coordination)·RPKI 기반 전역 검증이라는 네 가지 권고 행동을 제시한다.

동향 측면에서 눈여겨볼 지점은 보안의 무게중심이 '기술'에서 '거버넌스·프로세스'로 확장되고 있다는 것이다. 앞의 2025년 사회공학 사례가 보여 주듯, RPKI가 암호적으로 견고해질수록 공격자는 암호를 깨는 대신 사업자의 고객 등록·트랜짓 개통 절차의 허점을 노린다. 또 많은 대형 콘텐츠·클라우드 사업자(구글·클라우드플레어·넷플릭스 등)가 자사 prefix에 ROA를 걸고 상호접속 상대에게 ROV 집행을 요구하면서, RPKI가 상업적 협상 조건으로까지 자리 잡는 흐름도 나타난다. 표준 측면에서는 ROA 프로파일이 RFC 9582로 정리되고 ASPA가 표준화·초기 배포 단계로 넘어가면서, 라우팅 보안이 단일 기술이 아니라 여러 객체·절차의 조합으로 성숙해 가고 있다.

6. 고려사항 및 시사점 (기술사 관점)

적용 전략(단계적 성숙): RPKI 도입은 "ROA 등록 → RP 검증기 구축 → Invalid drop 정책 집행 → ASPA 등 보완"의 단계로 설계해야 한다. 특히 ROA를 만들었다고 보안이 완성되는 것이 아니라, Invalid를 실제로 폐기할 때 효과가 발생하므로, 커버리지 지표와 집행 지표를 분리해 관리(KPI화)하는 것이 핵심이다.
트레이드오프(가용성 vs 보안): Invalid를 강하게 차단할수록 보안은 높아지지만, ROA·인증서의 오설정이나 저장소·RP 장애로 정상 경로가 오탐 차단되면 광범위한 서비스 단절로 이어질 수 있다. 따라서 maxLength를 최소로 좁히되, RP 다중화·저장소 가용성(RRDP) 확보·변경 전 검증 등 운영 안전장치를 함께 설계해 보안과 가용성의 균형을 잡아야 한다.
거버넌스·신뢰 집중 리스크: 신뢰가 소수 RIR 트러스트 앵커에 집중되므로, 자원 회수·분쟁·국가적 압력 등으로 상위 인증서가 변경·취소될 때 하위 경로가 일괄 무효화될 위험(이른바 kill-switch 우려)을 제도적으로 통제해야 한다. 이는 순수 기술 문제가 아니라 자원 거버넌스·국제 협력의 문제로 다루어야 한다.
전망과 연계 기술: 라우팅 보안은 출처 검증(ROV)에서 경로 관계 검증(ASPA)으로, 나아가 경로 무결성(BGPsec)으로 확장되는 계층적 로드맵을 따른다. 중장기적으로는 양자내성암호(PQC)로의 서명 알고리즘 전환, DDoS·경로 이상 탐지와의 연계, 그리고 제로 트러스트 네트워크 관점에서 "신뢰하지 말고 검증하라"는 원칙을 도메인 간 라우팅까지 확장하는 방향으로 발전할 것으로 전망된다.
규제·정책과의 연계: 라우팅 보안은 개별 기업의 선택을 넘어 국가 기간통신망의 신뢰성 문제로 격상되고 있다. 미국이 통신사업자에게 라우팅 보안 계획 제출을 요구하는 등 규제화 움직임이 나타나며, 국내에서도 주요정보통신기반시설 보호와 통신재난 관리 관점에서 ROA 등록·ROV 집행을 점검 항목화하는 흐름이 예상된다. 기술사는 RPKI를 단일 기술 과제가 아니라 조달·계약(상호접속 조건)·컴플라이언스까지 묶은 라우팅 보안 거버넌스로 설계할 수 있어야 한다.

참고자료

IETF, "An Infrastructure to Support Secure Internet Routing" (RFC 6480) — https://www.rfc-editor.org/rfc/rfc6480
IETF, "A Profile for Route Origin Authorizations (ROAs)" (RFC 9582) — https://www.rfc-editor.org/rfc/rfc9582
IETF, "BGP Prefix Origin Validation" (RFC 6811) — https://www.rfc-editor.org/rfc/rfc6811
IETF, "The Resource Public Key Infrastructure (RPKI) to Router Protocol, Version 1" (RFC 8210) — https://www.rfc-editor.org/rfc/rfc8210
MANRS, "RPKI ROV Deployment Reaches Major Milestone" — https://manrs.org/2024/05/rpki-rov-deployment-reaches-major-milestone/
APNIC Blog, "RPKI vs social engineering: A case study in route hijacking" — https://blog.apnic.net/2026/03/31/rpki-vs-social-engineering-a-case-study-in-route-hijacking/

한 줄 요약: RPKI는 IP·AS 자원의 위임 계층을 인증서 신뢰 계층으로 사상해 "권한 있는 AS만이 prefix를 광고한다"를 증명하는 기반구조로, 그 위의 ROV로 출처 하이재킹·오설정을 막지만 경로 전체는 보증하지 못하므로 ASPA·BGPsec와의 단계적·계층적 적용과 'Invalid 폐기' 집행이 관건이다.