BGP는 인터넷에서 어느 자율 시스템(AS)이 어떤 IP 프리픽스를 광고하는지 전달합니다. 문제는 전통적인 BGP만으로는 “이 AS가 정말 이 주소를 광고할 권한이 있는가”를 암호학적으로 확인하기 어렵다는 점입니다.

RPKI(Resource Public Key Infrastructure)는 주소 자원 보유자가 ROA(Route Origin Authorization)를 발급해 허용할 origin ASN과 프리픽스 길이를 선언하게 합니다. 이 글은 RFC 6811의 Route Origin Validation 규칙, RFC 9582의 현재 ROA profile, RIPE NCC 공개 API를 기준으로 실제 도메인이 사용하는 주소의 valid, invalid_asn, invalid_length 결과를 직접 비교했습니다.

ROA가 허용하는 것은 두 가지다

ROA payload에는 핵심적으로 다음 정보가 있습니다.

  • 해당 프리픽스를 광고할 수 있는 origin AS
  • 광고할 수 있는 가장 구체적인 프리픽스 길이인 maxLength

예를 들어 104.21.0.0/20, origin AS13335, maxLength /20인 ROA가 있다면 정확히 /20을 AS13335가 origin으로 광고하는 조합은 허용됩니다. 같은 프리픽스를 다른 AS가 origin으로 광고하거나, AS13335라도 /24처럼 더 구체적인 경로를 광고하면 허용 범위를 벗어납니다.

ROA는 BGP 업데이트 자체에 붙어서 이동하지 않습니다. 라우터나 별도 validator가 RPKI 저장소에서 검증된 ROA payload를 받아 각 BGP 경로의 origin ASN과 프리픽스를 비교합니다.

실제 서비스 주소에서 프리픽스와 ASN을 찾았다

먼저 공개 DNS에서 확인한 IPv4 주소 104.21.15.131을 RIPEstat Network Info API에 질의했습니다. 응답은 이 주소가 104.21.0.0/20에 속하며 origin 후보가 AS13335임을 보여 줬습니다.

그다음 같은 프리픽스에 세 가지 조합을 넣어 RPKI Validation API를 호출했습니다.

curl -fsS \
  'https://stat.ripe.net/data/rpki-validation/data.json?resource=AS13335&prefix=104.21.0.0/20' \
  | jq '.data | {resource, prefix, status, validator}'

curl -fsS \
  'https://stat.ripe.net/data/rpki-validation/data.json?resource=AS64496&prefix=104.21.0.0/20' \
  | jq '.data | {resource, prefix, status, validator}'

curl -fsS \
  'https://stat.ripe.net/data/rpki-validation/data.json?resource=AS13335&prefix=104.21.15.0/24' \
  | jq '.data | {resource, prefix, status, validator}'

확인 결과는 다음과 같았습니다.

검증 조합 결과
AS13335, 104.21.0.0/20 valid
AS64496, 104.21.0.0/20 invalid_asn
AS13335, 104.21.15.0/24 invalid_length

세 응답의 validator는 모두 routinator로 표시됐습니다.

여기서 뒤의 두 질의는 실제 BGP 테이블에 그 잘못된 경로가 현재 존재한다고 주장하는 것이 아닙니다. 같은 검증 함수에 의도적으로 다른 origin ASN과 더 긴 프리픽스를 넣어 ROA 경계를 확인한 테스트입니다.

세 가지 표준 상태를 운영 언어로 바꾸면

RFC 6811의 기본 검증 상태는 Valid, Invalid, NotFound입니다. API는 Invalid의 원인을 ASN과 길이로 더 구체화해 보여 줍니다.

Valid

적어도 하나의 VRP(Validated ROA Payload)가 경로 프리픽스를 포괄하고, origin ASN이 일치하며, 경로 길이가 maxLength 이하인 상태입니다.

이 결과는 “origin이 이 프리픽스를 광고하도록 허가됐다”는 뜻입니다. 경로가 짧거나 안전하거나 최적이라는 뜻은 아닙니다.

Invalid ASN

프리픽스를 포괄하는 VRP는 있지만 BGP 경로의 origin ASN이 허용된 ASN과 다릅니다. 주소 오입력, ASN 전환 과정의 ROA 미갱신, 경로 유출 또는 하이재킹 후보가 될 수 있습니다.

운영자는 곧바로 공격이라고 단정하기보다 최근 ASN 이전, 멀티홈 구성, upstream의 집계 경로를 함께 확인해야 합니다.

Invalid Length

origin ASN은 맞을 수 있지만 광고 프리픽스가 ROA의 maxLength보다 더 구체적입니다. DDoS 완화나 트래픽 엔지니어링을 위해 /24를 새로 광고하면서 ROA를 /20까지만 허용해 둔 경우처럼 정상 변경에서도 발생할 수 있습니다.

그래도 검증 라우터가 Invalid를 거부하도록 운영된다면 정상 트래픽이 사라질 수 있으므로, BGP 변경 전에 ROA를 먼저 준비해야 합니다.

NotFound

해당 경로를 포괄하는 VRP가 하나도 없는 상태입니다. “안전하다”도 “공격이다”도 아닙니다. RPKI 권한 정보가 없어 원점 검증 결론을 낼 수 없다는 뜻입니다.

NotFound를 Invalid와 같은 방식으로 즉시 폐기하면 아직 ROA를 도입하지 않은 정상 네트워크를 대량 차단할 수 있습니다.

가장 중요한 한계: origin만 본다

RPKI Route Origin Validation은 이름 그대로 경로의 마지막 origin AS와 프리픽스 권한을 확인합니다. AS_PATH 전체가 실제로 그 순서로 전달됐는지는 검증하지 않습니다.

예를 들어 공격자가 허가된 origin ASN을 경로 끝에 남겨 두고 앞부분을 조작하면 origin 검증만으로는 AS_PATH 전체의 진위를 증명할 수 없습니다. 경로 누출, 비정상적으로 짧은 경로, 정책 위반 역시 ROA 하나로 모두 해결되지 않습니다.

따라서 ROV는 다음 관측과 함께 써야 합니다.

  • Route collector와 peer에서 본 AS_PATH 변화
  • 예상 upstream과 transit 관계
  • 갑작스러운 more-specific 광고
  • 지역별 도달성·지연 변화
  • IRR filter와 max-prefix 정책
  • BGPsec 같은 별도 경로 검증 기술의 적용 가능성

RPKI를 배포했다고 BGP 보안이 완료됐다고 표현하면 과장입니다. 더 정확한 표현은 “권한 없는 origin 광고를 걸러낼 수 있는 한 겹의 검증”입니다.

ROA 변경은 BGP보다 먼저 배포한다

실제 장애를 줄이려면 변경 순서가 중요합니다.

  1. 새 origin ASN과 광고 길이를 포함한 ROA를 먼저 발급한다.
  2. 여러 public validator와 내부 cache에서 VRP가 보이는지 확인한다.
  3. validator freshness와 RTR 세션 상태를 확인한다.
  4. 그다음 BGP 광고를 변경한다.
  5. 외부 관측점에서 Valid 상태와 실제 도달성을 함께 확인한다.
  6. 이전 경로를 철회한 뒤 불필요한 ROA 권한을 정리한다.

반대로 BGP를 먼저 바꾸면 전 세계에서 일부 ROV 네트워크만 새 경로를 거부하는 부분 장애가 생길 수 있습니다. 내부 모니터링은 정상인데 특정 ISP 사용자만 접속하지 못하는 형태라 찾기 어렵습니다.

maxLength를 필요 이상으로 넓게 주는 것도 피해야 합니다. 예를 들어 /16 자원에 /24까지 모두 허용하면 운영은 편하지만, 공격자가 더 구체적인 허용 경로를 악용할 여지도 커집니다. 실제 광고 계획에 필요한 최소 길이만 허용하는 것이 원칙입니다.

운영 점검표

  • 보유 프리픽스마다 예상 origin ASN과 ROA가 일치하는가
  • 실제 광고 길이가 maxLength를 넘지 않는가
  • ASN 이전과 DDoS 완화 경로를 변경 전에 등록했는가
  • validator 데이터가 오래됐을 때 라우터가 어떻게 동작하는가
  • Invalid와 NotFound를 서로 다른 정책으로 처리하는가
  • route collector에서 경로 변경을 별도로 감시하는가
  • ROA 발급 계정과 RPKI 키를 최소 권한으로 보호하는가
  • 복구 시 BGP와 ROA 중 무엇을 먼저 되돌릴지 문서화했는가

결론

직접 질의한 경로 조합에서 정상 origin과 길이는 valid, 다른 ASN은 invalid_asn, ROA보다 긴 프리픽스는 invalid_length로 구분됐습니다. RPKI가 무엇을 막는지 이해하기에 가장 명확한 실험입니다.

그러나 Valid는 경로 전체의 무결성 인증서가 아닙니다. origin 권한만 확인하며 AS_PATH 조작, 정책 위반, 경로 누출을 모두 해결하지 않습니다. 운영의 핵심은 최소 범위 ROA, 변경 전 전파 확인, Invalid·NotFound 분리 정책, 외부 BGP 관측을 함께 유지하는 것입니다.

이번 확인은 RIPEstat 공개 검증 API와 한 프리픽스의 ROA 경계를 사용했습니다. 실제 라우터에 reject 정책을 배포하거나 전 세계 peer의 경로 선택을 측정하지는 않았습니다.