서비스 공급자

OcNOS의 RPKI 경로 출처 검증: 피어링 엣지에서 ROV 구성

경로 출처 검증은 사업자가 인터넷 엣지에 추가할 수 있는 가장 저렴한 통제 수단이며, 선택 사항에서 필수 사항으로 바뀌었습니다. 이 가이드에서는 OcNOS에서의 동작 방식과 피어링 라우터에서의 구성 방법을 OcNOS-SP에서 검증된 명령어와 함께 설명합니다.

RPKI 경로 출처 검증이란?

Resource Public Key Infrastructure(RPKI)는 Route Origin Authorization(ROA)이라는 암호학적으로 서명된 레코드를 통해 IP 프리픽스를 이를 광고할 권한이 있는 네트워크에 연결합니다. Route Origin Validation(ROV)은 라우터가 수신한 BGP 경로를 이러한 ROA와 비교하여 valid, invalid 또는 not-found로 표시하는 동작입니다. 경로는 출처 AS와 프리픽스 길이가 ROA와 일치하면 valid, ROA는 존재하지만 출처나 길이가 틀리면 invalid, 해당 프리픽스를 포함하는 ROA가 없으면 not-found가 됩니다. ROV는 가장 흔한 라우팅 사고이자 공격, 즉 자신이 보유하지 않은 프리픽스를 광고하여 다른 사업자의 트래픽을 잘못된 방향으로 보내는 행위를 한 번에 차단합니다.

지금 RPKI가 중요한 이유

경로 출처 검증은 더 이상 있으면 좋은 기능이 아닙니다. 대형 트랜짓 사업자는 기본적으로 RPKI-invalid 경로를 거부하고, 각국 규제 기관은 지침에서 라우팅 보안을 언급하며, MANRS 조치는 출처 검증과 프리픽스 필터링을 제대로 된 네트워크의 기본 요건으로 취급합니다. 피어링 엣지에서 인터넷 전체 BGP 테이블을 보유하는 사업자에게 ROV는 아주 적은 노력으로 잘못된 출처라는 문제 전반을 제거합니다. 또한 이미 존재하는 모든 ROA의 혜택을 인터넷의 나머지 부분을 기다리지 않고 받으므로 즉시 보호를 얻을 수 있습니다.

OcNOS가 경로를 검증하는 방식

OcNOS는 RPKI 데이터베이스를 라우터에 저장하지 않습니다. 외부 RPKI 검증기(RPKI-to-Router(RTR) 캐시라고도 함)에 연결하여 트러스트 앵커에서 ROA를 가져와 암호학적으로 검증한 뒤, 검증된 프리픽스-출처 레코드 집합을 라우터에 전달합니다. OcNOS는 이 검증된 테이블을 메모리에 보관하고 타이머에 따라 갱신하며, 경로를 수신할 때마다 분류합니다. 이중화를 위해 라우터를 둘 이상의 검증기로 지정할 수 있습니다. RTR 프로토콜을 지원하는 검증기라면 Routinator, StayRTR와 함께 사용하는 rpki-client, NLnet Labs의 Krill 배포 등 무엇이든 동작합니다.

RPKI route origin validation on an OcNOS peering router: an RTR session to an RPKI validator supplies validated ROAs, a valid BGP route from the IXP is accepted, and an RPKI-invalid route is dropped at the peering edge before it reaches the core.
OcNOS 피어링 라우터는 RPKI 검증기와의 RTR 세션을 유지하며, valid 경로는 수용하고 RPKI-invalid 경로는 코어와 고객에 도달하기 전에 엣지에서 폐기합니다.

OcNOS에서 RPKI 경로 출처 검증을 구성하는 방법

구성은 세 부분으로 이루어집니다. 라우터를 검증기에 연결하고, 검증된 테이블이 채워지도록 하며, 그 결과에 따라 동작하는 정책을 적용합니다. OcNOS는 트랜잭션 방식이므로 각 단계는 다음 명령으로 적용합니다 commit.

1. 라우터를 RPKI 검증기에 연결

BGP 인스턴스 내에서 라우터를 하나 또는 두 개의 RTR 캐시로 지정합니다. 주소만으로 완전한 명령이 되며, port 는 선택 사항이며 TCP의 기본값은 3323입니다.

configure terminal
router bgp 64500
 bgp rpki server 10.0.0.10 port 3323
 bgp rpki server 10.0.0.11 port 3323
 commit

2. 검증 상태를 매칭하고 invalid 경로를 폐기

route-map를 사용하여 RPKI 상태에 따라 처리합니다. 이 route-map는 invalid 경로를 거부하고 나머지는 모두 허용하므로, valid와 not-found 경로는 수용되고 invalid 경로는 폐기됩니다.

route-map RPKI-EDGE-IN deny 10
 match rpki invalid
!
route-map RPKI-EDGE-IN permit 20
 commit

3. 피어링 세션 인바운드에 정책 적용

보호하려는 address family에서 route-map를 eBGP 피어에 연결합니다. 다음 아래에서도 반복합니다. address-family ipv6 unicast (IPv6의 경우).

router bgp 64500
 address-family ipv4 unicast
  neighbor 203.0.113.1 route-map RPKI-EDGE-IN in
  exit
 commit

RPKI 검증이 작동하는지 어떻게 확인하나요?

검증기 세션이 활성 상태인지, 검증된 테이블에 항목이 있는지, 경로가 표시되고 있는지 확인합니다. OcNOS는 이를 위한 세 가지 명령을 제공합니다.

OcNOS# show bgp rpki server
OcNOS# show bgp rpki table
OcNOS# show bgp rpki

show bgp rpki server 는 각 검증기와 해당 세션이 확립되었는지를 보고하고, show bgp rpki table 는 라우터가 다운로드한 검증된 프리픽스-출처 레코드를 나열하며, show bgp rpki 는 RPKI 상태를 요약합니다. 세션이 확립되고 테이블에 항목이 채워지면, 검증에 실패한 경로는 invalid 상태가 되어 엣지의 route-map에 의해 폐기됩니다.

피어링 엣지에서의 RPKI

Origin validation is one layer of a secure peering edge, not the whole of it. On a complete open peering router, RPKI invalid-route rejection sits alongside prefix filtering aligned with MANRS, BGP FlowSpec for DDoS mitigation, and remote-triggered black-holing, so the router enforces routing hygiene and attack response from the same place it carries the full table. See how the roles fit together on the 오픈 IP 코어 및 피어링 라우터.

공유