RPKI — 기초부터 운영까지

인프라 지도 · 용어정리 · BGP 하이재킹

RPKI 기반 ROV는 “이 IP 대역을 광고하는 origin AS가 허용된 AS인가?”를 확인한다. 전체 경로의 안전성이나 서비스의 신뢰성까지 보증하지는 않는다.

1. 학습 목표와 배경

IP 주소·CIDR 표기법을 알고 있으면 읽을 수 있다. 처음 접한다면 네트워크 기본과 용어정리의 Prefix부터 읽는다. 이 문서의 목표는 ROA·VRP·ROV를 구분하고, 검증 결과를 직접 판정하며, 운영 변경이 연결 장애로 이어지는 이유를 이해하는 것이다.

BGP는 네트워크 사이에서 도달 가능한 대역과 경로 정보를 교환한다. 그러나 경로를 받았다는 사실만으로 그 AS가 해당 대역을 기원할 권한이 확인되는 것은 아니다. RPKI는 IP 주소·AS 번호 할당 계층을 반영한 인증 기반이며, 주소 보유자가 경로 기원 권한을 서명해 공개하는 데 사용된다. RFC 6480

2. 전체 구조: 누가 누구를 신뢰하고 무엇을 검증하는가?

그림 1. 장비 아이콘으로 보는 RPKI 전체 구조. 금색은 인증서 발급·서명과 신뢰 기준, 파란색은 객체 수집·BGP 경로 전달, 초록색은 검증 결과 전달을 나타낸다. 라우터에서 캐시로 향하는 파란 점선은 RTR 연결 시작 방향이며 VRP는 반대 방향으로 전달된다. Validator와 RTR 캐시는 한 서버에 함께 두거나 분리할 수 있다. 일반적인 ROV 구조를 그렸으며 사용자 트래픽 경로를 나타내지는 않는다.

2.1. 라우터가 RPKI 인증서를 받아 서로 인증하는 것인가?

일반적인 ROV에서는 그렇게 동작하지 않는다. 내 라우터가 상대 BGP 라우터에게 ROA 인증서를 요구하고 상호 인증을 마친 뒤 경로를 받는 구조가 아니다. 인증서·서명 검증은 주로 Validator / RP가 수행하고, 내 라우터는 그 결과인 VRP를 받아 BGP 경로의 origin 권한을 대조한다.

“인증한다”라는 말을 다음 세 관계로 구분하면 이해하기 쉽다.

관계	무엇을 확인하는가?	어디서 수행하는가?
RPKI 객체 검증	ROA 서명이 유효하고, 인증서 체인이 신뢰 앵커에 연결되며 자원 범위·유효성 조건을 충족하는가?	Validator
RTR 연결 보호·인증	연결한 캐시·라우터가 의도한 상대이고, 전달 데이터가 변조되지 않도록 보호되는가?	라우터 ↔ RTR 캐시의 전송 계층
BGP 세션과 ROV	BGP로 받은 경로의 origin·길이가 로컬 VRP와 맞는가?	내 BGP 라우터

BGP 피어의 세션 인증은 별도 운영 설정이다. 세션 상대를 확인했다고 그 상대가 광고한 모든 프리픽스의 사용 권한까지 증명되는 것은 아니다. 반대로 ROV를 켠다고 BGP 피어와 인증서를 자동 교환하는 것도 아니다. RPKI 구조: RFC 6480 · ROV: RFC 6811 · BGP 보안: RFC 7454

2.2. 권한을 공개하고 라우터가 사용하는 순서

1. TA·CA·EE — 검증 가능한 권한 기반을 만든다. 자원 인증서는 IP·ASN 자원 사용 권한을 나타낸다. 주소 보유자는 허용할 프리픽스·origin ASN·길이를 정하고, EE 인증서에 대응하는 개인키로 ROA에 서명한다. hosted 서비스에서는 서비스가 인증서·키 작업을 대행할 수 있다.
2. 저장소 — 객체를 공개한다. 인증서·ROA·Manifest·CRL 등이 저장소에 게시된다. Validator는 RRDP(HTTPS 기반)나 rsync로 검증에 필요한 객체를 수집한다. 다운로드에 성공한 것만으로 객체가 신뢰되는 것은 아니다.
3. TAL·Validator — 신뢰 시작점을 확인하고 검증한다. 신뢰할 수 있게 설치한 TAL의 위치·공개키 정보로 TA를 확인한다. 그 기준에서 인증서 체인·서명·유효성·폐기 상태·자원 범위를 검증한다. 성공한 ROA에서 VRP를 얻는다.
4. RTR — 검증 결과를 내 라우터에 전달한다. 라우터를 RTR 클라이언트로, 검증 캐시를 서버로 설정한다. 라우터는 지정된 캐시에 연결하고 사용할 권한 정보를 받는다. ROA를 발급받는 절차가 아니다.
5. BGP·ROV — 실제 경로와 권한 정보를 비교한다. 이웃이 BGP UPDATE로 보내는 프리픽스와 AS_PATH에서 origin 정보를 얻어 로컬 VRP와 대조한다. 결과는 Valid·Invalid·NotFound다.
6. 정책·RIB·FIB — 판단을 전달 동작에 반영한다. 운영자가 정한 정책과 경로 선택을 적용하고, 선택된 경로가 전달 정보에 반영된다. 이후 패킷마다 원격 Validator에 인증을 요청하는 방식이 아니다.

권한 객체의 검증과 경로 비교는 RFC 6487, RFC 9582, RFC 6811을 참고한다. 저장소 동기화는 RFC 8182, 신뢰 시작점은 RFC 8630에 설명되어 있다.

2.3. 라우터와 Validator는 실제로 어떻게 연결하는가?

일반적인 설정 항목은 캐시 주소·포트·전송 방식·인증 정보·갱신 관련 설정이다. 지원 방식과 명령은 장비 및 소프트웨어 버전에 따라 확인한다.

• 일반 TCP: RFC 8210은 기본 RTR용 TCP 323을 정의한다. TCP 연결이 성공했다고 상대 인증이나 암호화가 제공되는 것은 아니다. 보호되지 않은 TCP를 사용할 때에는 신뢰·통제되는 망에서 접근을 제한해야 한다.
• 보호된 전송: RFC 8210에는 SSH·TLS·TCP-AO·IPsec 등의 방식이 기술되어 있다. 모든 제품이 이 방식을 전부 지원한다고 가정하지 않는다. TLS 인증서를 사용하더라도 이는 RTR 연결 상대를 인증하기 위한 것이며 ROA 자원 인증서와 목적이 다르다.

최초 데이터 수신 후에는 변경된 권한 정보를 갱신한다. 동기화에 필요한 이전 상태가 없으면 전체 데이터를 다시 받아야 할 수 있다. RTR 연결 정상, 데이터 최신, ROV 판정 정상, 거부 정책 적용은 각각 따로 확인할 항목이다. 연결·전송·동기화: RFC 8210

2.4. 하나의 경로를 끝까지 따라가 보기

학습용 VRP가 192.0.2.0/24, maxLength 25, AS64496이라고 하자.

순서	내 라우터가 보는 정보	의미
RTR 수신	위 VRP	Validator가 검증한 광고 권한
BGP 수신	192.0.2.0/25, AS_PATH 끝이 AS64496인 일반 AS_SEQUENCE	이웃이 전달한 실제 경로
ROV 비교	대역 포함·길이·origin 모두 일치	Valid
정책·경로 선택	다른 필터와 경로 속성도 함께 평가	Valid라도 반드시 최종 선택되는 것은 아님

여기서 이웃 라우터의 ASN과 origin ASN은 같지 않을 수 있다. 중간 사업자가 AS64496에서 시작한 경로를 전달했다면, ROV는 그 중간 사업자 ASN이 아니라 경로의 origin을 검사한다. Origin ASN과 BGP ORIGIN 속성도 구분한다. 용어정리 · RFC 6811

2.5. 구성요소별 역할 다시 보기

그림 2. 위쪽은 권한 정보의 공개·검증, 아래쪽은 검증 결과의 공급·적용이다. 화살표는 사용자 패킷의 이동을 나타내지 않는다.

구성요소	하는 일	하지 않는 일
자원 보유자	허용할 origin ASN과 프리픽스 지정	다른 사업자의 라우터 정책을 강제하지 않음
ROA	권한을 담은 서명된 객체	BGP 경로 광고 자체가 아님
Validator	인증서·서명·유효성·자원 범위 검증	일반적으로 사용자 패킷을 전달하지 않음
VRP	검증된 prefix·maxLength·ASN 정보	서명된 ROA 원본과 같은 객체가 아님
RTR	검증 캐시의 정보를 라우터에 공급	인터넷 전체에 경로를 광고하는 BGP가 아님
ROV와 정책	수신 경로를 판정하고 설정된 정책 적용	Valid라는 이유만으로 반드시 경로를 선택하지 않음

하나의 ROA에는 여러 프리픽스가 들어갈 수 있다. 따라서 ROA 개수와 VRP 개수가 항상 같지는 않다. 일반적인 구성에서 라우터는 매번 원본 인증서를 직접 검증하는 대신 Validator의 결과를 이용한다. ROA: RFC 9582 · RTR: RFC 8210

ROA를 등록하는 일과 ROV 필터를 적용하는 일은 별개다. 전자는 자신의 경로 권한을 공개하는 일이고, 후자는 수신한 경로에 운영자 정책을 적용하는 일이다. 검증 상태만 설정하고 거부 정책은 적용하지 않는 구성이 가능하다. RFC 8481

3. ROA와 maxLength 읽기

다음은 문서용 주소·ASN을 사용한 가상 권한 설정이다. 실인터넷 광고나 실장비 적용 예제가 아니다.

Prefix:     192.0.2.0/24
Origin ASN: AS64496
maxLength:  25

AS64496에 해당 /24와 그 안의 /25 광고를 허용한다. /26은 허용하지 않는다. maxLength는 주소 개수가 아니라 허용할 가장 긴 프리픽스 길이이며, 생략하면 지정한 프리픽스 길이만 허용한다. 실제 ROA 인코딩과 관리 포털의 표시 방식은 구분한다. RFC 9582 §4.3.2.2

4. 검증 상태를 직접 계산하기

그림 3. 포함하는 VRP가 없으면 NotFound, 하나라도 완전히 맞으면 Valid, 포함하지만 완전히 맞는 것이 없으면 Invalid다.

위 VRP 하나만 존재한다고 가정한다.

경로	Origin ASN	결과	이유
192.0.2.0/24	AS64496	Valid	모두 일치
192.0.2.0/25	AS64496	Valid	허용된 세부 대역
192.0.2.128/25	AS64496	Valid	다른 절반도 허용 범위
192.0.2.0/26	AS64496	Invalid	길이 초과
192.0.2.0/24	AS64497	Invalid	ASN 불일치
198.51.100.0/24	AS64496	NotFound	포함하는 VRP 없음

VRP가 겹칠 때에는 조건을 모두 만족하는 하나가 존재하는지 본다. 가장 구체적인 VRP 하나만 고르는 방식이 아니다. 결과는 현재 라우터가 보유한 검증 데이터에 대한 판정이므로 갱신 시점에도 영향을 받는다. RFC 6811 §2

5. 보장 범위: Valid는 안전 인증서가 아니다

ROV는 origin 권한을 검사하며, 전체 AS_PATH의 진위나 사업자 간 재광고 계약을 검증하지 않는다. 허용된 origin을 AS_PATH에 넣는 위조나, origin을 유지한 경로 유출은 별도 문제다. Invalid도 공격 외에 오설정·전환 작업의 불일치로 나타날 수 있다. 구체적인 차이는 하이재킹 문서에서 다룬다. RFC 9319 · RFC 7908

maxLength는 실제 광고 계획에 맞춰 제한한다. /24만 쓰는데 미래 편의를 위해 /32까지 허용하면 사용하지 않는 세부 대역도 권한 범위에 들어간다. 필요한 특정 하위 대역을 명시하는 방법을 먼저 검토한다. DDoS 방어 사업자가 대신 광고한다면 그 사업자의 origin ASN·대역·광고 기간도 확인해야 한다. maxLength 운영 권고: RFC 9319

6. 도입과 변경 절차

다음은 운영 지침을 바탕으로 정리한 실무 점검 순서다. 특정 장비의 실행 명령은 아니며, 장비·버전별 동작을 따로 검증한다.

1. 광고 목록 조사: IPv4·IPv6, 세부 대역, origin, 재해복구·DDoS 대응 경로까지 정리한다.
2. 권한 대조: 정상 광고가 Invalid가 되는 항목부터 원인을 해소한다.
3. 검증 데이터 관측: Validator 갱신, RTR 연결, 데이터 만료·급감을 감시한다.
4. 영향 검토: 거부될 경로와 대체 경로를 확인한 뒤 정책을 단계적으로 적용한다.
5. 외부 확인: 설정 화면뿐 아니라 다른 관측 지점의 광고·검증 상태도 확인한다.

Invalid 거부는 일반적인 운영 방향이지만 NotFound를 동일하게 취급하지 않는다. ASN 전환에서는 새 권한을 먼저 반영·확인한 뒤 경로를 바꾸고, 이전 경로 사용이 종료됐는지 확인한 후 이전 권한을 정리하는 순서를 검토한다. RFC 7115

7. 장애를 진단하는 순서

증상	첫 확인 항목	이어서 볼 항목
내 경로만 Invalid	Prefix·origin·maxLength	의도한 변경인지, 오래된 ROA인지
ROA 수정이 반영되지 않음	Validator의 최신 검증 결과	RTR 전달과 라우터 재평가
많은 상태가 동시에 바뀜	데이터 급감·만료	저장소 접근과 캐시 장애
라우터별 상태가 다름	사용하는 데이터와 갱신 시각	정책·캐시 구성 차이

RTR 연결이 끊겼다고 모든 경로가 즉시 Invalid로 바뀌는 것은 아니다. 남아 있는 데이터, 타이머와 다른 캐시 상태를 함께 확인한다. 데이터가 사라지면 포함하는 VRP가 없어지는 경로도 생길 수 있으므로 연결 상태만으로 보호 수준을 판단하면 안 된다. RFC 8210

새 검증 정보가 들어오면 과거에 거부된 경로도 다시 평가할 수 있어야 한다. RFC 9324는 필요한 경로를 보관해 RPKI 갱신 때마다 이웃에게 Route Refresh를 요청하지 않는 방법을 설명한다. RFC 9324

8. 복습 문제

1. ROA를 만들면 수신 경로 거부 정책도 자동 적용되는가?
2. ASN은 맞지만 허용 길이를 넘으면 어떻게 되는가?
3. NotFound와 Invalid를 구분해야 하는 이유는 무엇인가?
4. Valid인 경로도 위험할 수 있는 사례는 무엇인가?

정답: ① 별도 설정이다. ② 다른 일치 VRP가 없다면 Invalid다. ③ 검증 근거 부재와 권한 불일치는 다른 상태다. ④ origin 위조·경로 유출처럼 origin 권한 검사 범위를 벗어나는 사례가 있다.

함께 읽기

• 용어정리 — 약어와 헷갈리는 개념
• BGP 하이재킹 — 경로 탈취와 방어의 한계
• ROA 형식은 RFC 6482를 대체한 RFC 9582를 기준으로 읽는다.

자료 확인: 2026-10-27. 다이어그램은 이 문서를 위해 직접 제작한 개념도이며 실제 장애 관측 자료가 아니다.