- 들어가며 — 국가 차단이 국경을 넘던 날
- ROV가 실제로 한 일, 그리고 그 천장
- route leak — origin이 정당한 공격
- ASPA는 어떻게 동작하나 — up-ramp와 down-ramp
- 2026년 7월 10일, ASPA 스택이 라스트 콜에 들어갔다
- 그래서 오늘 얼마나 깔려 있나 — 직접 세어 봤다
- Unknown이 사실상 Valid다 — 부분 배포의 산수
- 스펙이 스스로 인정하는 한계
- 구현은 이미 3년 전에 나왔다
- 그래서 지금 무엇을 해야 하나
- 마치며
- 참고 자료
들어가며 — 국가 차단이 국경을 넘던 날
2026년 6월 16일, 인도 정부는 텔레그램 차단을 명령했습니다. NEET 의대 입시 재시험을 앞두고 조직적인 부정행위 채널이 문제가 됐고, IT법 69A조에 따라 6월 22일까지 차단하라는 명령이 내려왔습니다. 여기까지는 라우팅 이야기가 아닙니다.
문제는 차단하는 방법이었습니다. 인도 통신사 Rcom(AS18101, Reliance Communications이며 Reliance Jio가 아닙니다)은 텔레그램의 IP 대역을 BGP로 직접 광고해서 트래픽을 끌어와 블랙홀에 버리는 방식을 택했습니다. Kentik의 Doug Madory가 당시 BGP 데이터를 분석한 글에 따르면, 07:17 UTC부터 AS18101이 텔레그램이 쓰는 여러 IP 블록을 originate하기 시작했고, 그 경로가 인도 밖으로 새어 나갔습니다.
이건 아주 익숙한 실패 유형입니다. Madory의 표현으로는 의도적이면서 동시에 사고인 부류 — 국내용 차단이 국경 안에 머물지 못하고 전역 라우팅 테이블로 흘러나가는 패턴이고, 2008년 파키스탄 텔레콤의 유튜브 하이재킹이 그 원형입니다. 2021년 미얀마 쿠데타 때 트위터, 2022년 러시아, 브라질의 X 차단(AS263276), 2023년 8월 이라크의 텔레그램 차단이 모두 같은 모양이었습니다.
그런데 이번엔 숫자가 하나 남았습니다. Kentik 측정으로, 텔레그램(AS62041)이 정상 originate하던 91.108.4.0/22의 하이재킹 경로를 본 BGP 소스는 Kentik 자사 소스의 1.6%뿐이었습니다. Madory는 그 이유를 이렇게 적었습니다 — 텔레그램이 자기 경로 전부에 ROA를 걸어 뒀고, 그래서 네트워크들이 RPKI-invalid 경로를 버릴 수 있었기 때문일 가능성이 높다(likely owing to).
이 수치는 Kentik 자사 BGP 소스 기준의 벤더 자체 측정이고, Madory 본인이 인과를 단정하지 않고 "likely"로 적었다는 점을 그대로 옮겨 둡니다. 그래도 방향은 분명합니다. RPKI ROV는 2026년에 실제로 작동하는 방어입니다.
이 글은 그 사건에서 출발해, ROV가 실제로 막은 것이 정확히 무엇이고 어디서 천장에 부딪히는지, 그 천장 너머를 겨냥한 ASPA가 2026년 7월 현재 어디까지 왔는지를 봅니다. BGP·AS·피어링·RPKI의 기본기는 BGP 인터넷 라우팅 완전 가이드 편에서 이미 다뤘으니, 여기서는 2026년에 새로 벌어진 일만 다룹니다.
ROV가 실제로 한 일, 그리고 그 천장
ROV(Route Origin Validation, RFC 6811)가 하는 일은 딱 한 가지입니다. "이 프리픽스를 이 AS가 originate할 권한이 있는가"를 ROA(RFC 9582)에 서명된 내용과 대조하는 것. AS18101이 텔레그램 프리픽스를 자기 이름으로 originate하는 순간 origin이 어긋나므로, ROV를 켠 라우터는 그 경로를 invalid로 판정하고 버립니다. 그래서 전파가 1.6%에서 멈췄습니다.
무엇이 실패했는지도 공개돼 있습니다. 인도의 네트워크 연구자 Anurag Bhatia는 사건 다음 날 쓴 분석에서 이렇게 짚었습니다 — Rcom의 실수 외에 실제로 실패한 것은 업스트림들이 RPKI ROV를 하지 않은 것이고, 구체적으로 FLAG(AS15412)와 Tata Communications(AS4755)를 지목했습니다. 프리픽스에 서명이 돼 있었으니, ROV를 배포했다면 이 경로들은 쉽게 걸러졌고 AS18101과 그 다운스트림 안에 갇혔을 거라는 겁니다.
Bhatia는 91.105.192.0/23이 16:14:19 GMT(21:44:19 IST)에 AS18101에서 originate되기 시작한 것을 런던의 RIPE RIS RRC01을 포함한 여러 수집기에서 확인했다고 적었습니다. Madory의 타임라인과도 맞아떨어집니다 — 텔레그램이 IP 공간을 되찾으려고 more-specific 경로를 쏘자, AS18101이 16:14 UTC부터 그 more-specific까지 따라서 하이재킹했다는 대목이 그것입니다. 서로 독립적인 두 분석이 같은 시각을 가리킵니다.
그런데 Bhatia의 글에서 정말 중요한 문장은 따로 있습니다. 그는 이게 고의가 아니라 "fat finger mistake"라고 본다면서(이건 그의 개인적 판단입니다), 그 근거로 이렇게 씁니다:
진짜 의도적이었다면 origin ASN을 그대로 두고 텔레그램의 AS211157을 AS18101 뒤에 위조해 붙였을 것이다. 그러면 transit-free tier-1 계층과 여러 백본·IXP에 걸친 RPKI ROV 필터링이 아예 발동하지 않았을 것이다.
이 한 문장이 ROV의 천장을 정확히 그립니다. ROV는 AS_PATH의 맨 끝(origin)만 봅니다. 공격자가 origin 자리에 피해자의 ASN을 그대로 놔두고 자기를 그 앞에 끼워 넣으면, ROA 대조는 통과합니다. 경로가 완전히 거짓이어도 ROV는 아무 말도 하지 않습니다. 이번 사건에서 ROV가 이긴 건, 공격이 서툴러서 origin을 갈아 끼웠기 때문입니다.
route leak — origin이 정당한 공격
forged-origin 하이재킹보다 훨씬 흔한 것이 route leak입니다. RFC 7908이 정의하고 분류해 둔 이 현상은, 요약하면 경로가 받아서는 안 될 방향으로 재전파되는 것입니다. 고객이 공급자 A에게서 배운 경로를 다른 공급자 B에게 흘리면, B는 그 고객을 통해 A로 가는 경로를 배웁니다. 있어서는 안 될 경로지만 origin은 완벽히 정당합니다.
여기가 핵심입니다. route leak에서 origin은 진짜입니다. 프리픽스는 올바르게 서명돼 있고, originate한 AS도 ROA와 일치합니다. ROV는 이 경로를 valid로 판정합니다. 판정이 틀린 게 아니라, ROV가 대답하도록 설계된 질문이 아닌 겁니다. BGP는 경로를 받아들이고, 트래픽은 그 경로를 따라가고, 라우팅 테이블을 보는 운영자에게는 아무 신호도 뜨지 않습니다.
부분적인 방어는 이미 있습니다. RFC 9234가 정의한 OTC(Only to Customer) 속성은 BGP 세션에 role을 붙이고 "이 경로는 고객에게만"이라는 표시를 실어 우발적 route leak을 탐지·완화합니다. 하지만 OTC는 leak을 만드는 AS 자신이 규칙을 지켜야 작동합니다. 악의가 있는 쪽이 출발점이면 아무 소용이 없고, 그게 바로 ASPA 스펙이 도입부에서 인정하는 지점입니다 — RFC 9234는 accidental route leak을 다루고, ROV는 accidental mis-origination을 다룬다는 것.
ASPA는 어떻게 동작하나 — up-ramp와 down-ramp
ASPA(Autonomous System Provider Authorization)의 아이디어는 단순합니다. ROA가 "이 프리픽스는 이 AS가 originate한다"에 서명하듯, ASPA는 "내 공급자는 이들뿐이다"에 서명합니다. 객체 자체는 최소한입니다 — 프로파일 드래프트의 ASN.1을 보면 내용물은 customerASID 하나와 provider AS 목록이 전부입니다.
ASProviderAttestation ::= SEQUENCE {
version [0] INTEGER DEFAULT 0,
customerASID CAS,
providers ProviderASSet }
CAS ::= INTEGER (1..4294967295)
ProviderASSet ::= SEQUENCE (SIZE(1..MAX)) OF PAS
PAS ::= INTEGER (0..4294967295)
검증은 valley-free 원칙을 AS_PATH에 적용하는 것입니다. 검증 드래프트는 AS_PATH에서 연속 중복 ASN을 지운 COMPRESSED_AS_PATH를 놓고, 정상 경로라면 origin에서 올라가는 up-ramp와 수신자 쪽으로 내려오는 down-ramp 두 구간으로만 이뤄져야 한다고 봅니다. 각 홉은 customer-to-provider 관계여야 하고요. 스펙의 문장을 그대로 옮기면 이렇습니다 — up-ramp와 down-ramp의 길이 합이 N 이상이면 AS_PATH는 valid(route leak 없음)이고, 합이 N보다 작으면 경로가 leak됐거나 AS_PATH가 잘못된 것입니다.
AS(L) ............. AS(K)
/ \
. .
(down-ramp) . . (up-ramp)
. .
/ \
AS(N) AS(1)
/ (Origin AS)
수신·검증 AS (AS(N+1))
각 ramp는 아래에서 위 방향으로 연속된 customer-to-provider 홉
앞서 본 APNIC의 예(ASPA at APNIC)가 이걸 구체적으로 보여 줍니다. AS2가 AS1과 AS3 양쪽의 고객인데, AS1이 "내 공급자는 AS5뿐"이라는 ASPA를 발행해 뒀습니다. AS2가 AS1에게서 배운 경로를 실수로 AS3에 흘리면, AS3는 AS1의 ASPA를 조회해서 AS2가 AS1의 공급자로 등재돼 있지 않다는 걸 발견합니다. 경로는 ASPA-invalid가 되고 거부할 수 있습니다.
여기서 중요한 성질 하나 — 이 검증은 경로상의 모든 AS가 검증을 할 필요가 없습니다. APNIC의 두 번째 예처럼, 중간의 AS3가 검증을 안 하고 leak을 받아 넘겨도, 그 아래 AS4가 스스로 검증하면 "공급자 → 고객 → 다시 공급자"로 움직인 경로임을 발견해 잡아낼 수 있습니다.
2026년 7월 10일, ASPA 스택이 라스트 콜에 들어갔다
여기까지가 설계이고, 2026년의 뉴스는 이겁니다. 2026년 7월 10일, ASPA 관련 드래프트 세 건이 동시에 IETF 워킹그룹 라스트 콜(WGLC)에 들어갔습니다. IETF 데이터트래커의 문서 이벤트를 직접 조회하면 세 건 모두 같은 날 13:20~13:21에 "IETF WG state changed to In WG Last Call from WG Document"로 바뀐 것이 확인됩니다.
| 드래프트 | 리비전 | 상태 |
|---|---|---|
| draft-ietf-sidrops-aspa-profile | 27 (2026-06-19) | In WG Last Call (2026-07-10) |
| draft-ietf-sidrops-aspa-verification | 26 (2026-07-06) | In WG Last Call (2026-07-10) |
| draft-ietf-sidrops-8210bis (RTR v2) | 26 (2026-07-09) | In WG Last Call (2026-07-10) |
세 번째가 특히 중요합니다. RTR(RPKI-to-Router) 프로토콜은 검증기가 라우터에게 RPKI 데이터를 넘기는 통로인데, ASPA payload를 실어 나르려면 RTR 버전 2가 필요합니다. 즉 ASPA는 객체 프로파일·검증 절차·전달 프로토콜 세 층이 다 서야 굴러가고, 그 세 층이 같은 날 라스트 콜에 들어간 겁니다.
작년 말 시점의 예측과 대조해 보면 진도가 보입니다. Job Snijders는 2026년 2월에 쓴 RPKI 2025년 결산에서 "워킹그룹 라스트 콜이 가깝다! 운이 따르면 2026년 말에 스펙이 발행될 수도 있다"고 적었습니다. 라스트 콜은 그로부터 5개월 뒤에 실제로 시작됐습니다.
다만 아직 RFC가 아닙니다. 데이터트래커 상 세 문서 모두 rfc 필드가 비어 있고, IESG 상태는 "I-D Exists" — IESG가 처리를 시작조차 하지 않은 단계입니다. 라스트 콜은 워킹그룹 내부 절차일 뿐, 그 뒤에 IESG 검토와 RFC 에디터 큐가 남아 있습니다. 초기 리뷰는 이미 들어오고 있습니다 — 2026년 7월 15일에 ARTART 리뷰가 "Ready with Nits", BGPDIR 리뷰가 "Almost Ready"로 닫혔습니다.
그리고 RIR 쪽에서는 발행 기능이 이미 열렸습니다. RIPE NCC는 2025년 12월 15일 RPKI 대시보드에 ASPA를 추가했고, ARIN은 2026년 1월 20일 릴리스 노트에서 "ARIN's implementation of Autonomous System Provider Authorizations (ASPA) is now fully available in ARIN Online"이라고 공지했습니다. APNIC은 2026년 7월 9일 MyAPNIC과 Registry API 지원을 발표하면서, 2025년 11월 이후 RIPE NCC·ARIN·APNIC이 지원을 배포했고 2026년 말까지 5개 RIR 전부가 ASPA를 지원할 전망이라고 적었습니다.
그래서 오늘 얼마나 깔려 있나 — 직접 세어 봤다
스펙이 라스트 콜에 들어가고 RIR 세 곳이 발행 버튼을 열었다면, 실제 배포는 어디까지 왔을까요. 광고 문구 대신 세어 보는 게 낫습니다.
2026년 7월 16일 기준으로 두 개의 독립적인 소스를 봤습니다. 첫째, Job Snijders가 운영하는 rpki-client 콘솔의 ASPA 덤프를 받아 직접 파싱했습니다(페이지 생성 시각 Thu Jul 16 13:14:42 2026). 둘째, Hurricane Electric의 RPKI & ASPA 리포트를 같은 날 받았습니다.
두 소스가 거의 정확히 일치합니다.
| 항목 | 값 | 출처 |
|---|---|---|
| ASPA 객체 수 | 2,391 | HE.net |
| ASPA 객체 수 | 2,394 | rpki-client 콘솔 (직접 계수) |
| ASPA를 발행한 라우팅 테이블 내 ASN | 2,122 | HE.net |
| 라우팅 테이블 내 전체 ASN | 87,781 | HE.net |
| 라우팅 테이블 내 전체 ASN | 87,595 | RIPE RIS (2026-07-15) |
| ASPA 커버리지 | 2.42 퍼센트 | HE.net |
| 참고: 프리픽스 RPKI(ROA) 커버리지 | 67.36 퍼센트 | HE.net |
독립적인 두 도구가 객체 수에서 3개 차이, ASN 총수에서 200개 남짓 차이로 수렴합니다. HE.net의 내부 산수도 맞습니다 — RIR별 ASPA 보유 ASN을 더하면(RIPE 1,473 + ARIN 442 + LACNIC 107 + APNIC 100 + AFRINIC 0) 정확히 2,122이고, 2,122을 87,781로 나누면 2.42퍼센트입니다.
핵심은 마지막 두 줄의 대비입니다. ROA는 프리픽스의 67퍼센트를 덮었고, ASPA는 ASN의 2퍼센트대를 덮었습니다. 자릿수가 다릅니다.
RIR별로 쪼개면 배포 순서가 그대로 보입니다.
| RIR | ASPA 보유 ASN | 전체 ASN | 커버리지 |
|---|---|---|---|
| RIPE NCC | 1,473 | 31,738 | 4.64 퍼센트 |
| ARIN | 442 | 20,462 | 2.16 퍼센트 |
| LACNIC | 107 | 12,623 | 0.85 퍼센트 |
| APNIC | 100 | 20,307 | 0.49 퍼센트 |
| AFRINIC | 0 | 2,124 | 0 |
RIPE가 가장 먼저 열었으니 가장 높고, ARIN이 그다음, APNIC은 이번 달에 막 열었으니 0.49퍼센트, AFRINIC은 아직 지원 전이라 정확히 0입니다. 흥미로운 건 LACNIC의 107인데, APNIC 글의 서술대로면 LACNIC은 아직 지원 배포 전입니다. 제가 파싱한 발행 지점(publication point)을 보면 이 객체들은 rpki-repo.registro.br에서 나옵니다 — 브라질 NIC.br이 자체 CA를 운영하기 때문입니다. RIR의 호스팅 서비스를 기다리지 않고 위임 RPKI(delegated RPKI)로 직접 발행할 수 있다는 뜻이고, 실제로 제가 센 32개의 서로 다른 발행 호스트 중 상당수가 Krill을 돌리는 개별 조직들이었습니다.
증가 속도는 진짜입니다. Job Snijders의 결산 글에 있는 "Uniq ASPA Customer ASIDs" 게이지를 보면 2024년 말 87개에서 2025년 말 556개로 늘었습니다(+539퍼센트). 오늘 제가 센 고유 customer AS는 2,393개입니다. 1년 반 만에 87 → 556 → 2,393인 셈입니다.
동시에, 흔히 인용되는 수치는 이미 낡았습니다. "약 0.5퍼센트"라는 Job의 문장은 2026년 2월 시점의 것이고, 2026년 6월 말 RIPE Labs 글도 여전히 "well under 1% of the global ASN space"라고 적고 있습니다. 오늘 두 소스로 재면 2.42퍼센트입니다. 방향은 좋지만, 97.6퍼센트의 ASN에는 여전히 ASPA가 없다는 사실은 그대로입니다.
객체 자체의 모양도 몇 가지 보입니다. 제가 파싱한 2,394개 객체에 공급자 항목은 총 7,941개, 객체당 평균 3.32개, 중앙값 2개였습니다. 정확히 1개만 적은 객체가 718개(전체의 30퍼센트)로 가장 많았고, 최대는 204개를 나열한 AS14789였습니다. 공급자가 없다고 선언하는 AS0 ASPA는 59개였습니다. 그리고 검증 드래프트가 "AS는 단일 ASPA 객체를 등록해야 한다(SHOULD)"고 권고하는데, 2,394개 객체 중 이를 어긴 AS는 딱 하나(AS61574)였고 그마저 대학 연구 테스트베드였습니다. 권고는 사실상 지켜지고 있습니다.
Unknown이 사실상 Valid다 — 부분 배포의 산수
그럼 2.42퍼센트 커버리지에서 ASPA는 얼마나 일할까요. 스펙을 읽으면 답이 나옵니다. 그리고 이 부분이 이 글에서 가장 중요합니다.
ASPA 검증 결과는 세 값입니다 — Valid, Unknown, Invalid. 이 셋을 가르는 방식이 결정적입니다. 검증 드래프트 5.2절의 provider authorization 함수는 (AS x, AS y) 쌍에 대해 세 가지를 반환합니다: AS x의 ASPA가 없거나 유효하지 않으면 "No Attestation", ASPA가 있고 AS y가 목록에 있으면 "Provider+", 있는데 목록에 없으면 "Not Provider+".
그리고 5.3절이 ramp 길이의 상한과 하한을 이렇게 정의합니다.
max_up_ramp: "Not Provider+" 가 처음 나오는 지점까지. 즉 ASPA가 없는 홉은 낙관적으로 ramp에 포함시킵니다.min_up_ramp: "No Attestation" 또는 "Not Provider+" 가 처음 나오는 지점까지. 즉 ASPA가 없으면 거기서 끊습니다(비관적).
판정은 이렇게 갈립니다.
max_up_ramp + max_down_ramp < N -> Invalid
min_up_ramp + min_down_ramp < N -> Unknown (정보 부족)
그 외 -> Valid
여기서 도출되는 결론이 있습니다. Invalid가 나오려면 누군가 ASPA를 발행했고, 그 ASPA가 문제의 홉을 명시적으로 부정해야 합니다. ASPA가 그냥 없으면 "No Attestation"이고, 그건 max 계산에 걸리지 않으므로 Invalid가 될 수 없습니다. 결과는 Unknown입니다.
그리고 5.6절의 권고 완화 정책은 이렇습니다 — Invalid면 경로 선택에서 배제(단, 재평가를 위해 Adj-RIB-In에는 보관). 그런데 Unknown으로 평가된 경로는 Valid와 같은 선호 수준으로 취급해야 한다(SHOULD).
이 둘을 합치면 오늘의 현실이 나옵니다. 커버리지가 2.42퍼센트라는 건, 임의의 AS_PATH에서 leak이 일어난 바로 그 지점의 AS가 ASPA를 발행해 뒀을 확률이 낮다는 뜻입니다. 그러면 판정은 Unknown이고, Unknown은 Valid처럼 취급되고, 아무 일도 일어나지 않습니다. RIPE Labs에 실린 ASPA Is Live. Can You See It Working?에서 저자가 실제 RPKI 데이터로 랩을 돌린 결과도 같습니다 — 대부분의 경로가 Unknown으로 뜨는데, 경로가 수상해서가 아니라 대부분의 운영자가 아직 ASPA 객체를 등록하지 않았기 때문이라는 것.
이건 버그가 아니라 설계입니다. 부분 배포에서 오탐(false positive)으로 멀쩡한 경로를 죽이지 않으려면 이렇게 보수적이어야 합니다. ROV도 같은 길을 걸었습니다. 대신 대가가 분명합니다 — ASPA를 켜는 것은 오늘 당장은 거의 아무것도 막아 주지 않습니다. 이득은 커버리지가 쌓인 뒤에 옵니다.
스펙이 스스로 인정하는 한계
ASPA를 route leak의 만능 해결책으로 파는 글이 많은데, 정작 스펙이 자기 한계를 꽤 정직하게 적어 놨습니다. 읽어 볼 만합니다.
공급자가 고객을 하이재킹하는 경우는 못 잡습니다. 7.3절은 이렇게 말합니다 — 공급자는 forged-origin/forged-segment AS_PATH로 직간접 고객의 프리픽스를 하이재킹할 수 있고, 고객에게 보내는 경로의 AS_PATH를 조작할 수도 있으며, 이런 공격은 ASPA로 탐지되지 않을 수 있다. 스펙의 방어 논리는 기술적이지 않고 계약적입니다 — 이론상 가능하지만 현실적인 시나리오로 보이지 않고, 보통 고객과 공급자 사이엔 서명된 계약이 있어 이런 정책 위반은 법적 결과를 낳거나 고객이 그냥 관계를 끊고 해당 ASPA 레코드를 지우면 된다는 것. 설득력은 각자 판단할 문제지만, 위협 모델의 일부를 계약으로 미뤄 뒀다는 점은 알고 쓰는 게 맞습니다.
AS_PATH prepend 조작은 못 잡습니다. 7.4절 — ASPA 검증 절차는 AS_PATH에서 AS 번호 반복의 제거나 추가를 탐지할 수 없습니다. 다만 스펙은 이 공격 자체가 route leak 탐지 능력에는 영향을 주지 않는다고 덧붙입니다.
자기가 시작하는 leak은 못 막습니다. 8.4절이 명시합니다 — ASPA 기반 검증은 AS_PATH에 앞서 등장한 AS들이 만든 route leak을 탐지·완화하지만, 로컬 AS가 자기 이웃에게 leak을 시작하는 것은 막지 못합니다. 또 경로에 Complex 관계가 있으면 leak 탐지에 실패할 수 있습니다. 그래서 스펙은 OTC 속성(RFC 9234)이 그 빈칸을 메우며, ASPA 검증을 보완하기 위해 OTC 절차 구현을 권고(RECOMMENDED)한다고 적습니다. ASPA는 OTC의 대체재가 아니라 짝입니다.
ASPA가 틀리면 손해는 양방향입니다. 7.2절 — 공급자를 잘못 넣으면 leak 탐지 능력이 줄고, 공급자를 빠뜨리면 멀쩡한 경로가 나중에 ASPA Invalid로 떨어질 수 있습니다. 그래서 4절은 DDoS 완화 업체 같은 대기(standby) 공급자나 비상용 공급자를 미리 넣어 두라고 권고합니다. ASPA 전파와 경로 전파 사이의 경쟁 조건을 피하기 위해서입니다. 운영적으로는 이게 제일 아픈 대목입니다 — 비상시에 트래픽을 우회시키려는 바로 그 순간, 등재해 두지 않은 공급자를 통한 경로가 Invalid로 죽습니다.
IPv4/IPv6 비대칭은 관대한 쪽으로 뭉갭니다. 7.1절 — 공급자 집합은 IPv4와 IPv6를 합쳐서 하나로 관리하므로, 한쪽 주소 체계에만 존재하는 고객-공급자 관계가 다른 쪽에도 허용되는 것처럼 보입니다. 스펙은 이를 등록·검증이 단순해지고 오탐이 없다는 이유로 "합리적인 타협"이라고 부릅니다.
구현은 이미 3년 전에 나왔다
배포가 안 된 이유가 코드가 없어서는 아닙니다.
- OpenBGPD는 검증 드래프트의 구현 현황 절에 따르면 7.8 이상에서 ASPA를 지원합니다. GitHub의 openbgpd-portable 태그를 확인하면 7.8은 2023년 2월 3일에 나왔습니다. 3년 5개월 전입니다.
- BIRD는 자체 NEWS 파일 기준으로 2.16(2024-12-04) 에서 "ASPA support in filters, Static and RPKI"를 넣었고, 이후 2.16.1에서 파서 버그, 2.18(2025-12-26)에서 AS_SET 처리, 2.19.0(2026-05-25)에서 downstream 검증을 고쳤습니다. 활발히 유지되고 있다는 뜻입니다.
- Routinator(NLnet Labs)는 0.13.0에서 ASPA와 RTR 버전 2 지원을 넣었고, 0.14.1(2025-01-22)부터는 항상 컴파일에 포함됩니다. 다만 지금도
--enable-aspa옵션으로 명시적으로 켜야 합니다 — 공식 문서에서 ASPA는 여전히 "Advanced Features" 항목이고, "현재 IETF의 두 인터넷 드래프트에 기술된"이라는 단서가 붙어 있습니다. - 상용 벤더는 아직입니다. 검증 드래프트가 기록한 건 2025년 Cisco의 IOS-XR 기반 Early Field Trial 구현이고, 그 외에 RTRlib, NIST-BGP-SRx(IXP/RS 확장 미지원), FreeRTR가 올라 있습니다. APNIC은 "여러 상용 벤더가 지원을 출시했거나 개발 중"이라고 적었지만 어느 벤더인지는 밝히지 않았습니다.
한 가지 덧붙이면, 드래프트의 구현 현황 절은 이미 낡았습니다. BIRD 항목은 여전히 "side branch(mq-aspa)에 있고 릴리스는 RTR v2 확정 이후로 예상"이라고 적혀 있는데, BIRD의 NEWS는 2.16부터 릴리스에 들어갔다고 말합니다. 이건 드래프트를 탓할 일은 아닙니다 — 해당 절 스스로가 "여기 실린 정보를 독립적으로 검증하는 데는 아무 노력도 들이지 않았으며, 기여자들이 제출한 내용"이라고 밝히고 있고, RFC로 발행되기 전에 삭제될 절이라고 명시합니다. 다만 이 절을 벤더 지원 현황표로 읽으면 안 된다는 뜻이기는 합니다.
정리하면 이렇습니다. 오픈소스 라우터에서 ASPA 검증 코드는 3년 전부터 있었고, 커버리지는 2.42퍼센트입니다. 병목은 코드가 아니라 객체와, 그 객체를 실제로 강제할 결심입니다.
그래서 지금 무엇을 해야 하나
지금 할 만한 것: ASPA 객체를 발행하는 것. 이건 비대칭적으로 싼 행동입니다. 내가 ASPA를 발행하면 이득을 보는 건 내가 아니라, 내 경로를 검증하는 남들입니다(그리고 내 프리픽스가 leak됐을 때 그걸 잡아 주는 것도 남들의 검증기입니다). 내 라우터가 뭘 켤 필요도 없고, 내 트래픽에 영향도 없습니다. RIPE NCC·ARIN·APNIC 회원이면 대시보드에서 됩니다. 그 셋이 아니어도 위임 RPKI로 발행할 수 있다는 건 위의 registro.br 사례가 보여 줍니다. 주의할 점은 위에 적은 대로 — 대기·비상 공급자를 빠뜨리지 말고, AS당 객체는 하나로, 그리고 공급자 관계가 바뀌면 갱신하는 운영 루틴을 만드는 것입니다. 갱신을 잊은 ASPA는 나중에 자기 경로를 죽입니다.
아직 서두를 필요 없는 것: ASPA Invalid를 거부하도록 켜는 것. 커버리지가 2.42퍼센트인 지금, 켜서 얻는 방어는 거의 없고 잘못 등록된 ASPA 때문에 멀쩡한 경로를 죽일 위험은 실재합니다. 게다가 스펙은 아직 RFC가 아니고, 라스트 콜 리뷰에서 "Almost Ready" 판정이 나온 참입니다. RTR v2도 같은 큐에 있습니다. 로깅 모드로 관찰하면서(6.6절이 로깅을 따로 다룹니다) 커버리지가 오르는 걸 보는 게 지금 단계에 맞습니다.
여전히 우선순위가 높은 것: ROV. 이 글의 출발점이 그 증거입니다. 텔레그램 사건에서 실제로 피해를 만든 건 ROV를 하지 않은 업스트림들이었고, 피해를 막은 건 ROV를 하는 나머지였습니다. ROA 커버리지는 67퍼센트고 ASPA는 2퍼센트대입니다. ROV를 아직 강제하지 않고 있다면, ASPA를 알아보기 전에 그걸 먼저 하는 게 맞습니다. 그리고 RFC 9234의 OTC를 함께 보십시오 — ASPA 스펙 자신이 OTC를 보완재로 권고하고, OTC는 이미 RFC이며, 내가 남에게 leak을 시작하는 것을 막아 주는 유일한 층입니다.
ASPA가 당신 문제가 아닐 수도 있습니다. 업스트림이 하나뿐인 스텁 AS라면, 발행은 몇 분이면 끝나고(공급자 하나짜리 ASPA — 오늘 전체의 30퍼센트가 이 모양입니다) 검증을 직접 돌릴 이유는 별로 없습니다. 검증이 값을 하는 건 여러 피어와 트랜짓에서 경로를 받는 네트워크입니다.
마치며
2026년 6월의 텔레그램 사건은 RPKI ROV가 실제로 일한다는 증거입니다. Kentik 측정으로 하이재킹 경로는 자사 소스의 1.6퍼센트에만 닿았고, Madory와 Bhatia 둘 다 그 원인으로 텔레그램의 ROA와 상류의 필터링을 지목했습니다. 2008년 파키스탄-유튜브 때와 비교하면 인터넷은 분명히 나아졌습니다.
동시에 그 사건은 천장을 보여 줍니다. Bhatia가 짚은 대로, 이번에 ROV가 이긴 건 공격이 origin을 갈아 끼우는 서투른 방식이었기 때문입니다. origin을 그대로 두고 자기를 앞에 끼워 넣었다면 ROV는 침묵했을 것이고, 애초에 route leak은 origin이 정당하므로 ROV의 질문 자체에 걸리지 않습니다.
ASPA는 그 빈칸을 겨냥한 다음 층이고, 2026년은 그 층이 형태를 갖춘 해입니다 — 7월 10일에 세 드래프트가 라스트 콜에 들어갔고, RIR 세 곳이 발행을 열었고, 연말까지 다섯 곳 전부가 열릴 전망입니다. 구현은 OpenBGPD에 3년 전부터 있었습니다.
그런데 오늘 세어 보면 2.42퍼센트입니다. 그리고 검증 알고리즘의 구조상, 커버리지가 낮으면 판정은 Unknown이고 Unknown은 Valid와 같은 대접을 받습니다. 즉 ASPA는 지금 켜져 있어도 아직 거의 아무것도 막지 않습니다. 이건 실패가 아니라 이 종류의 기술이 배포되는 방식입니다 — ROA도 87개에서 시작했고 지금 프리픽스의 67퍼센트를 덮습니다.
그러니 결론은 시시하지만 분명합니다. 발행은 지금 하고, 강제는 아직 하지 말고, ROV와 OTC를 먼저 챙기십시오. 그리고 어떤 숫자를 인용하기 전에, 오늘 날짜로 직접 세어 보십시오 — "well under 1%"라는 문장이 2026년 하반기의 글에도 계속 실려 나오는 동안, 두 개의 독립적인 소스로 오늘 재 본 값은 2.42퍼센트였습니다.
참고 자료
- When Local Blocks Go Global: The India-Telegram BGP Incident — Doug Madory, Kentik
- Telegram prefixes hijack by Rcom AS18101 — Anurag Bhatia
- draft-ietf-sidrops-aspa-verification — BGP AS_PATH Verification Based on ASPA Objects
- draft-ietf-sidrops-aspa-profile — A Profile for Autonomous System Provider Authorization
- draft-ietf-sidrops-8210bis — The RPKI to Router Protocol, Version 2
- RFC 9234 — Route Leak Prevention and Detection Using Roles in UPDATE and OPEN Messages
- RFC 7908 — Problem Definition and Classification of BGP Route Leaks
- RFC 6811 — BGP Prefix Origin Validation
- RFC 9582 — A Profile for Route Origin Authorizations (ROAs)
- ASPA at APNIC: Strengthening BGP path validation — APNIC Blog
- RPKI's 2025 year in review — Job Snijders, APNIC Blog
- ASPA in the RPKI Dashboard — Tim Bruijnzeels, RIPE Labs
- ASPA Is Live. Can You See It Working? — Ritesh Mukherjee, RIPE Labs
- New Features Added to ARIN Online (2026-01-20)
- The RPKI Console — ASPA 객체 덤프
- Hurricane Electric — RPKI & ASPA Adoption Report
- Routinator — Advanced Features (ASPA)
- BGP 인터넷 라우팅 완전 가이드 — AS, Peering, Path Selection, RPKI(관련 글)
현재 단락 (1/124)
2026년 6월 16일, 인도 정부는 텔레그램 차단을 명령했습니다. NEET 의대 입시 재시험을 앞두고 조직적인 부정행위 채널이 문제가 됐고, IT법 69A조에 따라 6월 22일까...