요약

  • 2012년 11월 6일 UTC 기준 약 02:24경, Cloudflare는 인터넷 일부 지역에서 Google 서비스에 접근할 수 없는 현상을 관찰했고, Google 주소로 향하는 경로가 정상적인 Google 오리진인 AS15169에 앞서 Moratel(AS23947)과 PCCW(AS3491)를 거치는 것을 추적했습니다 [1].
  • Cloudflare는 이 장애를 약 27분 동안 지속된 제한적 장애로 설명했습니다. 인터넷 인구의 3~5퍼센트가 영향을 받았을 수 있으며 홍콩 주변에서 영향이 더 컸다고 추산했습니다. 이 수치는 완전한 독립 전수 조사가 아니라 Cloudflare의 추정치로 남아 있습니다 [1].
  • RFC 7908은 이후 Moratel-PCCW 사건을 4유형(Type 4) 경로 유출로 등재했습니다. 피어 프리픽스가 트랜짓 제공자 쪽으로 유출되어 의도된 범위를 넘어 전파된 사례입니다 [2].
  • Cloudflare는 처음에 잘못된 경로 고지가 원인일 가능성이 높다고 평가했습니다. 이후 업데이트는 Moratel의 발표를 기록했는데, 예기치 못한 하드웨어 장애가 비정상 상태를 만들었으며 이 사건은 악의적 행위가 아니라는 내용이었습니다 [1]. 공개 기록에는 정확한 장애 양상을 판정할 만한 내부 증거가 충분히 담겨 있지 않습니다.
  • 책임 표면은 수출과 수입 양쪽에 걸쳐 있습니다. Moratel은 무단 경로가 해당 세션에서 빠져나가지 못하도록 해야 했고, PCCW는 수용 가능한 고객 경로와 다른 관계를 통해 학습한 경로를 구분해야 했습니다. 탐지, 철회, 증거 보존, 검증된 복구는 공동의 운영 의무였습니다.

공개 기록이 보여주는 것

Cloudflare는 자사 직원들이 UTC 기준 약 02:24경 자사 네트워크에서 Google 서비스가 접속 불가 상태임을 알아차렸다고 보고했습니다. 조사는 DNS 접근성 실패, 즉 Google 공용 리졸버인 8.8.8.8에 닿지 못하는 현상에서 시작되었습니다. 이어진 추적 결과, Cloudflare의 캘리포니아 네트워크에서 Google로 향하는 트래픽이 인도네시아의 Moratel 주소를 거치는 예상 밖의 경로를 지나고 있음이 드러났습니다 [1].

Cloudflare가 관찰한 Google 프리픽스 경로에는 AS4436, AS3491, AS23947, AS15169 순서가 포함되어 있었습니다. 이 순서에서 AS15169는 여전히 Google 오리진이었습니다. 비정상 지점은 그 오리진에 도달하는 데 쓰인 경로였습니다. Cloudflare가 해당 관계를 통해 받을 것으로 기대하지 않은 경로에서 Moratel이 PCCW와 Google 사이에 나타났습니다 [1]. Cloudflare는 Google 공용 DNS 프리픽스에서도 동일한 패턴을 관찰했습니다.

이 구분이 중요합니다. 이 사건은 알려지지 않은 네트워크가 Google 주소 공간을 오리진으로 발표하는 것으로 제시되지 않았습니다. 정당한 오리진에 연관된 경로가 잘못된 관계 경계를 가로질러 전파된 전파 장애였습니다. 경로 끝의 목적지 신원은 여전히 옳을 수 있지만, 경로 중간의 트래픽은 해당 트래픽을 운반할 준비나 권한이 없는 네트워크 쪽으로 향했을 수 있습니다.

Cloudflare는 Moratel의 담당자에게 연락했다고 밝혔습니다. 경로 고지는 UTC 기준 약 02:50경 정정되었고, 약 3분 뒤 라우팅은 정상으로 돌아왔습니다 [1]. 이 글은 27분간의 제한적 장애와 아시아 일부 지역, 특히 홍콩 주변에서 더 큰 영향을 추산했습니다. 다만 이 글은 그 추산을 전 세계 장애 건수로 확장하지 않습니다. Cloudflare는 유용한 운영 관측 지점이었지만, 모든 사용자, 모든 네트워크, 모든 Google 서비스를 관찰하지는 못했습니다.

같은 출처에는 중요한 정정도 남아 있습니다. 원래 분석은 Moratel의 누군가가 잘못된 경로 변경을 했을 가능성이 높다고 말했습니다. 이후 업데이트는 Moratel의 발표를 기록했는데, 예기치 못한 하드웨어 장애가 비정상 상태를 초래했고 이 사건은 악의적이지 않으며, Moratel이 장애를 점검하는 동안 해당 BGP 피어링을 차단했다는 내용이었습니다 [1]. Moratel의 라우터 로그, 하드웨어 경보, 구성 이력, 인시던트 타임라인이 없다면, 최초의 통제 실패가 하드웨어, 소프트웨어, 구성, 페일오버 동작 또는 그 상호작용 가운데 무엇이었는지 공개적으로 판정할 수 없습니다.

RFC 7908이 이를 4유형 경로 유출로 분류하는 이유

인터넷은 자율 시스템(autonomous system)으로 나뉩니다. 각 자율 시스템은 자율 시스템 번호로 식별되며 자체 라우팅 정책을 적용하고, 보더 게이트웨이 프로토콜(BGP)로 이웃 네트워크와 도달성 정보를 교환합니다. 경로 고지는 주소 프리픽스, AS 경로, 기타 속성을 담습니다. 운영자는 그다음 어떤 경로를 수용하고, 선호하고, 다시 광고할지 결정합니다.

이러한 결정은 기술적일 뿐만이 아닙니다. 비즈니스 및 운영 관계를 부호화합니다. 고객은 일반적으로 더 넓은 인터넷에 대한 도달성을 제공자에게 비용을 지불하고 얻습니다. 피어는 일반적으로 서로의 고객에 대한 경로만 교환하며, 학습한 모든 경로에 대한 완전한 트랜짓을 주고받지 않습니다. 익스체인지의 라우트 서버는 또 다른 역할을 맡습니다. 따라서 동일한 프리픽스가 어떤 세션에서는 유효하고, 다른 세션으로 수출될 때는 무효가 될 수 있습니다.

RFC 7908은 경로 유출을 라우팅 고지가 의도된 범위를 넘어 전파되는 것으로 정의합니다. 그 4유형 항목은 측면 피어(lateral peer)에서 학습한 경로를 자신의 트랜짓 제공자 쪽으로 유출하는 네트워크를 다룹니다. 이 RFC는 Google 프리픽스의 Moratel-PCCW 유출을 예시로 명명하며, 이 사건으로 Google 서비스가 접속 불가가 되었다고 기술합니다 [2].

이 분류는 사건에 정밀한 책임 프레임을 부여합니다. 핵심 질문은 AS15169가 Google 프리픽스를 오리진으로 발표할 자격이 있었는지 여부만이 아닙니다. AS23947이 학습한 Google 경로를 AS3491 쪽으로 수출할 자격이 있었는지, 그리고 AS3491이 해당 고객 또는 트랜짓 정책 하에서 이를 수용·전파했어야 했는지입니다.

오리진 검증만으로 그 관계 질문에 답할 수 없습니다. 경로가 올바른 오리진 ASN에서 끝나더라도 무단 제공자·고객·피어 전환을 포함할 수 있습니다. 따라서 2012년 사건은 경로 정책 계층에 속합니다. 레지스트리 기록과 오리진 인가는 여전히 유용하지만, 세션 역할, 수출 정책, 수입 필터, 경로 수준 증거를 대체하지 못합니다.

수출 측 증거 의무

첫 번째 증거 의무는 경로를 수출하는 네트워크에 있습니다. Moratel은 관련 BGP 세션이 무엇인지, 이웃에 부여된 역할이 무엇인지, 해당 세션에서 학습한 경로, 로컬에서 선택한 경로, PCCW 쪽으로 광고한 경로를 식별할 수 있어야 했습니다. 그 기록은 자체 오리진 프리픽스, 고객 프리픽스, 피어에서 학습한 경로, 제공자에서 학습한 경로를 구분해야 합니다.

인시던트 종결 보고는 그다음 실행 중인 경로를 승인된 정책과 연결해야 합니다. 하드웨어 장애가 비정상 상태를 초래했다면, 유용한 증거는 그 장애가 라우팅 상태를 어떻게 바꿨는지 보여야 합니다. 라인 카드나 라우트 프로세서가 불완전한 정책과 함께 재시작했는가? 페일오버 경로가 다른 구성을 활성화했는가? 손상되었거나 오래된 정책 개체가 관계별 필터를 대체했는가? 라우터가 수렴 중 더 넓은 테이블을 광고했는가? 공개 출처는 이 질문들에 답하지 않습니다.

설명과 증거의 차이가 중요합니다. "하드웨어 장애"는 유발 요인의 한 부류를 가리킬 뿐입니다. 경로 수출이 어떻게 실패 시 열리는(fail open) 상태가 될 수 있었는지는 보여주지 않습니다. 견고한 수출 정책은 예기치 못한 장치 상태가 피어 학습 경로를 고객 경로로 변환하는 능력을 줄여야 합니다. 그러려면 세션 경계에서의 명시적 정책, 그 세션을 빠져나갈 수 있는 경로의 제한, 실제 광고 경로 집합에 대한 모니터링이 필요합니다.

수출 측 운영자는 변경 전후 기록도 보존해야 합니다. 구성 diff는 유용하지만 그것만으로는 부족합니다. 운영자는 경로 정보베이스, 이웃에 광고된 경로, 관련 커뮤니티나 속성, 세션 리셋, 하드웨어 이벤트, 타임스탬프, 철회 순서를 필요로 합니다. 이 기록들은 복구가 증상만 바꿨는지, 아니면 유출을 허용한 통제 경로를 닫았는지 드러냅니다.

업스트림 수용 의무

두 번째 증거 의무는 경로를 받는 네트워크에 있습니다. Cloudflare는 PCCW를 Moratel의 업스트림 제공자로 기술하고, PCCW가 Moratel이 보낸 경로를 신뢰하고 전파했다고 말했습니다 [1]. 현재 RDAP는 AS3491을 PCCWG-APAC-HK로 식별하며 PCCW Global (HK) Limited와 연관시킵니다 [6]. 이 현재 신원 증거는 디렉터리 연속성을 뒷받침합니다. 그러나 그것만으로 2012년 당시의 모든 상업 조건이나 세션 역할을 증명하지는 못합니다.

업스트림은 수동 파이프가 아닙니다. 어떤 고객 고지를 수용할지, 어떻게 분류할지, 어디로 전파할지 선택합니다. 제3자 경로를 정당하게 운반할 수 있는 고객에게는 오리진 전용 허용목록만으로는 어려움이 있습니다. 그 어려움이 수용 의무를 없애지는 못합니다. 오히려 관계 기록과 프로비저닝 시스템을 더 중요하게 만듭니다.

수용 측 운영자는 고객이 어떤 프리픽스와 경로를 고지할 권한이 있었는지, 그 인가가 어떻게 생성되고 얼마나 자주 대조되었는지, 어떤 최대 프리픽스·경로 수 통제가 적용되었는지, 어떤 비정상 오리진이나 경로 패턴이 경보를 발생시켰는지, 누가 차단을 무시할 권한을 가졌는지 보여줄 수 있어야 합니다. 수용된 경로가 의도된 고객 범위 밖이었다면, 종결 보고는 수입 정책이 왜 그것을 거부하지 않았는지 밝혀야 합니다.

경로 유출이 공동 인시던트가 되는 이유는 전파 단계마다 영향 반경이 커지기 때문입니다. 고객이 최초의 잘못된 수출을 할 수 있지만, 큰 업스트림은 국소적 결함을 널리 보이는 경로로 바꿀 수 있습니다. 따라서 책임은 "고객이 보냈다"로 끝날 수 없습니다. 업스트림의 상품은 통제된 전파입니다. 그 증거는 비정상 고지가 수용되고, 선택되고, 다시 광고된 지점을 보여야 합니다.

현재 레지스트리 기록이 증명할 수 있는 것과 없는 것

현재 APNIC RDAP는 AS23947을 MORATELINDONAP-AS-ID로 식별하고 운영 연락처를 PT. Mora Telematika Indonesia와 연관시킵니다 [5]. AS3491의 현재 RDAP는 PCCWG-APAC-HK와 PCCW Global (HK) Limited를 식별합니다 [6]. 이 기록들은 자율 시스템 번호를 현재 네트워크 신원에 결합하는 데 도움이 됩니다.

그러나 2012년 사건 전체를 재구성하지는 못합니다. 레지스트리 데이터는 누가 번호 자원을 보유하거나 운영하는지, 책임 조직에 어떻게 연락하는지를 기록할 수 있습니다. 하지만 02:24 UTC에 어떤 라우터가 어떤 경로를 수용했는지, 어떤 상업 관계가 세션에 적용되었는지, 어떤 필터 버전이 활성 상태였는지, 어떤 하드웨어 상태가 바뀌었는지는 보여주지 않습니다.

이것이 이 글의 Heng.lu 표면입니다. 레지스트리는 실행 중인 네트워크의 대체물이 아니라 원장이자 기록 보관자입니다. ASN 기록의 정확성은 운영자가 내구성 있는 신원, 연락처, 이전 연속성을 필요로 하기 때문에 중요합니다. 책임 판정은 여전히 그 기록을 실제로 실행된 경로, 그 경로를 제약했어야 할 정책, 복구 후 보존된 증거와 대조하는 데서 나옵니다.

8.8.8.0/24에 대한 RIPEstat의 과거 라우팅 응답은 요청한 날 동안 AS15169가 오리진으로 관측되었음을 보여줍니다 [4]. 응답의 분해능은 8시간이므로, 수명이 짧은 유출된 AS 경로나 그 분 단위 철회를 증명할 수 없습니다. 따라서 이 글은 사건 경로에 대해서는 Cloudflare의 당시 경로 관측과 RFC 7908의 후속 분류에 의존하고, RIPEstat 응답은 범위가 한정된 과거 맥락으로만 다룹니다.

페일 클로즈(fail closed)되어야 할 통제

첫 번째 통제는 명시적 수입·수출 정책입니다. 모든 외부 BGP 세션에는 정의된 역할과 그 역할을 반영하는 경로 정책이 있어야 합니다. 정책이 없다고 해서 전체 테이블을 수용하거나 광고하는 것이 기본값이 되어서는 안 됩니다. 피어에서 학습한 경로가 조용히 제공자 쪽으로 수출 가능해져서는 안 됩니다.

두 번째 통제는 실행 구성에 결합된 프로비저닝 원장입니다. 원장은 이웃 ASN, 관계 역할, 인가된 프리픽스 또는 고객 범위, 허용된 오리진, 기대 경로 패턴, 경로 한도, 변경 담당자, 승인 기록을 식별해야 합니다. 자동화는 그 의도를 장치 정책으로 컴파일하고 배포된 정책이 승인된 기록과 일치하는지 검증해야 합니다.

세 번째 통제는 경로 집합 모니터링입니다. 운영자는 각 이웃에 광고되는 경로를 기대 집합과 비교해야 합니다. 제3자 프리픽스가 갑자기 많이 나타나거나, AS 경로에 예상 밖의 업스트림이 있거나, 고객이 인가된 관계 밖의 경로를 광고하면, 넓은 전파 전에 봉쇄가 발동되어야 합니다.

네 번째 통제는 관계 인지 신호입니다. 사건 이후 훨씬 나중에 공표된 RFC 9234는 BGP 역할(Roles)과 Only-to-Customer 속성을 규정합니다. 이 메커니즘은 관계 경계를 기계 판독 가능하게 만들고 기대 전파 규칙을 위반하는 경로의 탐지를 돕습니다 [3]. 이는 유용한 통제 맥락이지, 2012년 어느 운영사가 이를 사용했다는 증거가 아닙니다.

다섯 번째 통제는 독립적 경로 관측입니다. 외부 수집기와 네트워크 관측 지점은 양쪽 인접 운영사가 자국 로컬 구성이 옳다고 믿더라도 경로가 의도된 경계를 벗어났음을 보여줄 수 있습니다. 수집기 증거는 타임스탬프와 함께 보존되어 라우터 로그와 비교되어야 합니다. 운영자 자신의 Adj-RIB-In, 로컬 결정, Adj-RIB-Out 증거를 대체해서는 안 됩니다.

여섯 번째 통제는 테스트된 철회 경로입니다. 복구는 나쁜 고지를 멈추는 것 이상에 달려 있습니다. 운영자는 철회가 얼마나 빨리 전파되는지, 오래된 경로가 남는지, 캐시와 제어 평면 수렴이 사용자 도달성에 어떤 영향을 주는지, 어떤 외부 관측자가 경로 소멸을 확인하는지 알아야 합니다.

유용한 공개 종결 보고

유용한 공개 종결 보고는 범위가 한정된 타임라인으로 시작합니다. 최초 관측 증상, 최초 내부 경보, 최초 확인된 비정상 경로, 운영자 간 최초 접촉, 수출 중단, 철회 가시성, 안정적 복구가 그것입니다. UTC를 사용하고 관측 시각과 진단 시각을 구분해야 합니다.

이어서 영향받은 경로 부류를 명시해야 합니다. 종결 보고는 민감한 전체 구성을 공개할 필요가 없습니다. 피어 학습 경로가 트랜짓 제공자 쪽으로 수출되었는지, 활성 정책이 누락·노후·우회되었는지, 수신 네트워크의 고객 필터가 승인 집합 밖의 경로를 수용했는지만 말할 수 있습니다.

종결 보고는 불확실성을 보존해야 합니다. 하드웨어 장애가 사건을 촉발했다면, 운영자는 증거가 뒷받침하는 것 이상의 정밀성을 주장하지 않으면서 통제 효과를 설명해야 합니다. 내부 로그가 더 이상 존재하지 않는다면, 그 부재 자체가 연속성 발견 사항입니다. 그것은 운영자가 복구가 가시 경로를 철회한 것뿐 아니라 원인까지 다루었음을 증명하는 능력을 제한합니다.

마지막으로 종결 보고는 내구성 있는 변화와 그 검증 방식을 명시해야 합니다. "필터를 업데이트했다"는 진술은 의도된 관계, 생성된 정책, 배포된 정책 해시, 거부된 테스트 경로, 경보 기준치, 롤백 담당자, 외부 경로 관측 검증을 보여주는 증거보다 약합니다. 목표는 민감한 네트워크 세부사항을 노출하는 것이 아니라 재발 주장을 감사 가능하게 만드는 것입니다.

이 사건이 여전히 중요한 이유

사건은 오래되었지만 통제 문제는 현재진행형입니다. BGP는 여전히, 각자의 로컬 정책이 원격 사용자에게 비용을 부과할 수 있는 독립 운영 네트워크들을 결합합니다. 경로 오리진 보안은 개선되었고 관계 인지 표준도 발전했지만, 올바른 오리진이 곧 정당한 경로를 의미하지는 않습니다.

이 사건은 또한 짧은 장애에도 규율 있는 증거가 필요한 이유를 보여줍니다. 27분 사건은 경로가 복구된 뒤 일과성 문제로 치부될 수 있습니다. 영향받은 사용자에게는 서비스가 여전히 접속 불가였습니다. 운영자에게는 그 짧은 기간이 비정상 경로, 하드웨어 상태, 경로 수출, 이웃 수용을 함께 포착할 수 있는 유일한 창일 수 있습니다.

가장 강력한 결론은 협소합니다. 공개 증거는 2012년 11월 6일 Moratel-PCCW 경로 유출이 Google 서비스 도달성에 영향을 주었고, Cloudflare가 비정상 경로를 관측하고 문제 제기에 기여했으며, RFC 7908이 이후 이 사건을 피어-투-트랜짓 유출로 분류했다는 점을 뒷받침합니다 [1][2]. 공개 증거는 내부 실패 순서나 최종 책임 분배를 확정하지 않습니다. 그 공백이 책임 의무를 정의합니다. 다음 설명이 단순히 수용되는 것이 아니라 검증될 수 있도록, 충분한 실행 상태 증거를 보존하는 것입니다.

출처

  1. https://blog.cloudflare.com/why-google-went-offline-today-and-a-bit-about/
  2. https://www.rfc-editor.org/rfc/rfc7908.txt
  3. https://www.rfc-editor.org/rfc/rfc9234.txt
  4. https://stat.ripe.net/data/routing-history/data.json?resource=8.8.8.0/24&starttime=2012-11-06T00:00:00&endtime=2012-11-07T00:00:00
  5. https://rdap.apnic.net/autnum/23947
  6. https://rdap.arin.net/registry/autnum/3491