BGP 처리 버그로 인터넷 라우팅 불안정성 발생

 (blog.benjojo.co.uk)
1P by GN⁺ | ★ favorite | 댓글 1개
  • 2025년 5월 20일 07:00 UTC에 전파된 손상된 BGP 메시지가 주요 구현 2종에서 예상 밖 동작을 일으켜, 다수의 인터넷 연결 BGP 세션이 리셋되고 일부 네트워크에서 라우팅 불안정이나 짧은 연결 손실이 발생함
  • 문제 업데이트에는 인터넷 BGP 업데이트에서 일반적으로 기대되지 않는 BGP Prefix-SID Attribute가 붙어 있었고, 내부 데이터가 모두 0x00인 손상 상태였음
  • RFC7606 기반 오류 허용을 적용한 IOS-XR/Nokia SR-OS는 이를 걸러냈지만, JunOS는 전달했고 Arista EOS는 세션을 리셋해 JunOS 기반 transit carrier에 연결된 Arista 사용자에게 영향을 줄 수 있었음
  • bgp.tools 관측에서는 AS9304, AS135338, AS151326, AS138077이 반복 등장했으며, 결함 속성을 추가한 주체는 Starcloud AS135338 또는 Hutchison AS9304일 가능성이 높음
  • 사고 중 bgp.tools route collector의 10초 평균 메시지율이 평시 초당 20,000~30,000개에서 150,000/s 초과로 뛰어, BGP 오류 처리 차이가 실제 인터넷 경로 안정성을 흔들 수 있음을 보여줌

2025년 5월 20일 BGP 업데이트 사고

  • 2025년 5월 20일 화요일 07:00 UTC에 전파된 BGP 메시지가 인터넷 트래픽 전달에 자주 쓰이는 주요 BGP 구현 2종에서 예상 밖 동작을 유발함
  • 많은 인터넷 연결 BGP 세션이 자동 종료되면서 영향이 확산됨
    • 일부 네트워크에서 라우팅 불안정이 확인됨
    • 최악의 경우 짧은 연결 손실이 발생했을 수 있음

문제가 된 BGP 메시지

  • bgp.tools에 공급되는 세션에서 확인된 업데이트는 /16에 대한 비교적 평범한 BGP Update였지만, 문제가 되는 BGP Prefix-SID Attribute를 포함함
  • 해당 속성은 두 가지 이유로 위험했음
    • 인터넷 테이블 BGP 업데이트에서 보일 것으로 기대되지 않는 속성임
    • 내부 데이터가 모두 0x00인 손상된 속성임
  • IOS-XR/Nokia SR-OS 같은 대부분의 구현은 RFC7606 기반 “BGP error tolerance”가 설정된 경우 이를 올바르게 걸러내 문제를 일으키지 않음
  • JunOS와 Arista EOS 조합에서는 다른 결과가 나타남
    • JunOS는 손상된 메시지를 전달함
    • Arista EOS 장비는 JunOS 장비에서 온 것으로 보이는 해당 메시지를 받으면 세션을 리셋함
  • 많은 인터넷 transit carrier가 JunOS를 실행하는 Juniper 하드웨어를 쓰기 때문에, Arista EOS를 운영하면서 JunOS 기반 상위 transit carrier 라우터에 연결된 네트워크는 일정 시간 인터넷 접근이 끊겼을 가능성이 있음
    • 지속 시간은 최대 약 10분으로 추정됨

결함 속성을 추가한 후보 AS

  • 해당 기간의 bgp.tools 아카이브를 필터링한 결과, 여러 origin AS가 사고에 관여한 것으로 보임
  • 이는 속성이 prefix를 origin한 네트워크가 아니라, 더 넓은 인터넷으로 가는 중간 carrier에서 추가됐을 가능성을 시사함
  • 문제 메시지 전체에서 반복 등장한 후보는 다음 4개임
    • AS9304 — Hutchison Global Communications Limited
    • AS135338 — Starcloud Information Limited
    • AS151326 — DCConnect Communication Pte. Ltd.
    • AS138077 — PT Abhinawa Sumberdaya Asia
  • bgp.tools는 […] 151326 138077 […] 경로에서 결함 있는 BGP 속성 없이 impacted prefix를 관측함
    • 따라서 결함 속성을 추가한 주체는 Starcloud AS135338 또는 Hutchison AS9304일 가능성이 높음
  • 속성을 포함한 업데이트에서 관측된 일부 prefix는 다음과 같음
    • 156.230.0.0/16
    • 138.113.116.0/24
    • 163.171.102.0/24
    • 163.171.103.0/24
    • 163.171.104.0/24

인터넷 익스체인지로 번진 경로

  • 사고는 Hutchison/AS9304가 많은 인터넷 익스체인지에 연결돼 있었기 때문에 더 커짐
  • 문제 메시지는 IX route server로 보내졌고, 이 route server들은 보통 bird를 실행함
  • Bird는 BGP SID를 지원하지 않아 메시지를 필터링하지 못했고, 여러 multi-terabit 인터넷 익스체인지로 그대로 배포함
  • 그 결과 혼란은 인터넷 transit 세션을 넘어 더 넓은 범위로 확산됨

BGP Prefix-SID의 성격

  • BGP Prefix-SID Attribute는 일반적으로 내부 BGP 세션에서만 보여야 함
  • RFC8669에서 정의된 목적은 단일 네트워크 안에서 목적지까지 트래픽이 어떤 경로를 택할지 정하는 데 도움을 주는 것임
  • 이 속성이 글로벌 라우팅 테이블로 새어 나온 이유는 외부 BGP 세션이 내부 세션처럼 설정됐기 때문일 수 있음

영향을 받은 네트워크와 관측 지표

  • 정확히 누가 영향을 받았는지 단정하기는 어렵지만, 최초 문제 BGP 메시지 직후 네트워크 규모 대비 churn이 매우 컸던 곳을 기준으로 약 100개 네트워크가 문제를 겪은 것으로 집계됨
  • 높은 신뢰도로 든 예시는 다음과 같음
  • 평상시 bgp.tools route collector는 초당 약 20,000~30,000개 메시지를 수집함
  • 이번 사고 중 10초 평균 메시지율은 150,000/s를 크게 넘음
    • 많은 인터넷 경로에 상당한 장애가 있었음을 나타냄

벤더별 오류 처리 차이

  • 근본 원인이나 실제 유발 주체가 완전히 명확하지는 않지만, 결함 메시지가 인터넷 규모로 전파된 사실은 BGP 오류 처리의 위험을 보여줌
  • 다른 벤더들은 결함 속성을 감지하고 라우트 공지를 억제했지만, Juniper는 이를 peer로 전파함
  • 해당 메시지가 Arista 장비에 도달한 뒤에는 BGP error tolerance 코드가 없었거나 결함이 있어 세션 리셋으로 이어짐
  • Juniper의 JunOS BGP error tolerance 문서는 JunOS가 메시지의 모든 부분을 살피지는 않는다고 밝힘
  • 이 동작은 JunOS 자신은 원격 유발 세션 리셋을 피하면서, 같은 메시지를 다른 peer 또는 고객 쪽으로 전달하는 결과를 낳음

운영상 함의

  • 이번 outage는 짧았지만 더 큰 영향을 낳을 수도 있었음
  • 더 많은 서비스가 IP 기반으로 이동하면서 인터넷 장애의 범위는 이메일 접근 실패를 넘어설 수 있음
    • TV 방송 실패
    • 긴급 서비스 전화 장애
  • 이런 버그는 실제 세계의 인명 피해를 유발하거나 악화시킬 가능성을 높임
  • 전체 라우팅 테이블을 가진 네트워크 운영자는 bgp.tools에 데이터 피드를 제공해 향후 사고 디버깅에 도움을 줄 수 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 표준 접근은 받아들일 때는 관대하고 내보낼 때는 엄격해야 한다는 것임
    선택지는 깨진 메시지를 필터링하거나, 버리거나, 깨진 속성은 무시하되 전달하거나, 깨진 속성 때문에 망가지는 것인데, 진짜 받아들이기 어려운 건 4번인 Arista식 동작뿐이라고 봄. 3번인 Juniper식 동작은 바람직하진 않아도 치명적이진 않음
    다시 읽어보니 Arista는 4번이 아니라 2번에 가까웠고, 완전히 크래시한 게 아니라 잘못된 연결로 보고 닫은 듯함. 사용자 입장에선 좋지 않지만, 논쟁적으로는 허용 가능한 편임

    • 이미 RFC 7606(Revised Error Handling for BGP UPDATE Messages)이 있고, 깨진 BGP 메시지를 어떻게 처리해야 하는지 자세히 정해 둠
      가장 흔한 방식은 treat-as-withdraw로, 경로 발표 업데이트를 기존 발표 경로 철회처럼 처리하는 것임. 깨진 메시지를 그냥 버리면 더 이상 유효하지 않은 오래된 상태를 계속 유지하게 되므로 그러면 안 됨
    • 여기서 바꿔 말한 건 이른바 견고성 원칙, 즉 Postel의 법칙임
      1980년대와 90년대 인터넷 고대사에서 나온 발상인데, 오늘날에는 프로토콜 경직화와 수많은 보안 문제를 낳은 잘못된 아이디어로 널리 이해되고 있음
    • 문제는 BGP가 로컬 장비가 이해하지 못하는 알 수 없는 속성도 전달하는 동작을 사람들이 네트워크 전체에서 온갖 용도로 활용했다는 데 있음
      이제 많은 시스템이 그 동작에 의존하고 있고, 그 “기능”의 단점을 겪는 중임
    • 관련 글에서 저자가 같은 지점을 짚음
      겉보기에는 이 “기능”이, 전달하는 정보의 영향을 이해하지 못하는 시스템을 통해 알 수 없는 정보가 맹목적으로 퍼지게 하므로 매우 나쁜 아이디어처럼 보임. 하지만 이 기능 덕분에 Large Communities 같은 것들이 더 빠르게 널리 배포될 수 있었고, 새로운 BGP 기능 배포 자체가 가능해졌다고도 볼 수 있음
    • 이 접근에는 동의하지 않음. 받아들이는 것도 매우 엄격하고, 내보내는 것도 매우 엄격한 편이 더 낫다고 봄

  • 전체 네트워크에서 CVE-2023-4481을 고치려고 미친 듯이 뛰어다녔던 일이 아직도 기억남
    이런 종류의 버그는 처리하기 정말 악몽 같을 것이고, BGP가 설계·구현된 방식 때문에 이런 동작을 고치는 데 아주 오래 걸릴 것임

  • 수십 년 전이긴 하지만 통신 장비 업체에서 BGP 기능을 개발했었음
    여전히 BGP는 너무 복잡하다고 생각하고, 사람들은 계속 새 기능을 추가하며 업체들은 RFC 표준이나 초안을 기준으로 계속 구현함
    BGP가 폐기될 것 같지도 않으니 이런 버그는 앞으로도 계속 반복해서 발견될 듯함

    • 한때 AT&T가 Juniper, Cisco와 함께 MPLS와 VPN 관련 기능을 통해 BGP를 완전히 복잡한 영역으로 밀어 넣던 시기가 분명 있었음
      개인적으로는 무서울 정도로 복잡했지만, 누군가에게는 수익성이 좋았음

  • HGC Global Communications Limited는 이전에 Hutchison Global Communications Limited로 알려졌던 회사로, 홍콩의 인터넷 서비스 제공자임
    https://en.wikipedia.org/wiki/HGC_Global_Communications

  • 우리 IOS XR 섀시들도 이런 패킷을 일부 받았고, 높은 BGP 경로 광고와 시점이 맞아떨어졌음. 상위망이 어떤 장비를 쓰는지는 솔직히 모름
    BGP 프로토콜이 제대로 퍼징되고 있는지 궁금해짐. 너무 중요해서 다들 망가뜨려 보기를 겁내는 분야일 수도 있음
    BGP 퍼저를 작성하는 건 쉬울 수 있지만, 크래시 원인을 진단하기는 매우 어려울 것 같음

  • BGP는 문제를 일으킨다는 얘기를 듣기 전까지 배운 적이 없던 것 같음. TCP/IP처럼 인터넷에 필수적인데도 TCP/IP는 대학에서도 배우고, 커리어 중에도 접하고, 책도 많이 읽었지만 BGP는 대학·직장·책 어디에서도 거의 접하지 못했음
    TCP/IP는 집에서 장난감 프로젝트로 “놀아” 보며 배울 수 있는데, BGP는 어떻게 해봐야 할지 모르겠음. 집에서 BGP를 배우려면 어떻게 해야 하나?

    • BGP 구현이 들어간 라우터를 사면 됨. Mikrotik 같은 저렴한 장비도 있고, 오픈소스 구현도 있음
      글에는 bird가 나오고, 또 매우 인기 있는 구현으로 FRR(free range routing)이 있음. Docker 컨테이너 두 개를 띄워 그 사이에 BGP 세션을 만들고, 예를 들어 내부에 설정한 정적 경로를 전파하는 건 아주 간단함
      안내형 튜토리얼을 좋아한다면 https://blog.ipspace.net/2023/08/bgp-labs-basic-setup/가 꽤 좋고, 조금 더 고급 주제까지 확장되어 있음. 따라 하는 데 필요한 것은 모두 자유 소프트웨어임
    • DN42[1]는 라우팅 기술을 실험해볼 수 있는 놀이터를 제공함. 많은 시간을 들일 생각이 없다면 깊게 파고드는 건 추천하지 않음. 네트워킹에 꽤 익숙한 입장에서도 WAN 라우팅은 여전히 헷갈림
      어떤 네트워킹 기술이든 직접 경험해보는 가장 쉬운 방법은 아마 GNS3일 것임
      [1]: https://wiki.dn42.us/home
    • BGP는 국제 해운 같은 것임. 세상이 돌아가려면 반드시 있어야 하지만, 대부분의 사람은 직접 상호작용할 필요가 없음
      실험해보는 한 방법은 이런 것임: https://www.eve-ng.net/
      다른 방법은 네트워크 인터페이스가 몇 개 달린 가상 머신 두어 개를 만들고, 그 사이에 네트워크를 구성한 뒤 BGP 라우팅 데몬을 쓰는 것임
      https://bird.network.cz/
      https://www.nongnu.org/quagga/
      같은 것들이 있음
    • 학부 네트워킹 수업에서는 BGP를 다루지 않았고, 대학원 네트워킹 수업에서는 다뤘음
      여러 AS를 시뮬레이션하는 Python 패키지를 썼는데, 어떤 패키지였는지는 기억나지 않음
    • 학부 네트워크 수업에서 BGP를 조금 다루긴 했지만 칠판 설명뿐이었음
      BGP를 실험하려면 이 글의 저자처럼 네트워크 시뮬레이터를 쓸 수 있음. 수업에서는 교수님의 대학원생이 만든 것 같은 gini[1]를 썼고, 저자는 Cisco 특화 ns3 버전처럼 보이는 gns3를 쓴 듯함. ns3는 한 번 써봤는데 학습 곡선이 가팔랐음. gini 시뮬레이터는 사용자 인터페이스가 더 기본적이지만 아마 기능은 덜 강력할 것임
      [1] https://citelab.github.io/gini5/
      [2] https://docs.gns3.com/docs/

  • 여러 하드웨어 업체가 이런 종류의 일을 처리하는 표준 방식에 합의했다면 BGP는 훨씬 더 안정적이었을 것처럼 보임
    진짜 문제는 각 업체가 종속 효과를 원해서 표준화하지 않는 데 있는 걸까?
    단, BGP에 대한 이해는 얕고 빈약하며 전문가가 아님

  • 이런 버그의 영향을 생각하면 상호운용성 테스트 스위트를 가진 컨소시엄이 없다는 게 놀라움
    어쩌면 있긴 한데 이 특정 문제가 테스트 스위트에 없을 수도 있음. 그렇다면 퍼저나 기계 생성 방식으로 가능한 패킷 오류를 전부 탐색해 테스트 케이스를 만들지 않는다는 게 놀라움. 스위트 실행에 몇 시간이나 며칠이 걸려도 괜찮을 텐데
    이 글의 저자는 어느 정도 커버리지를 가진 퍼저를 만들었고, 전에도 비슷한 문제를 만난 듯함. 업체들이 이 작업을 적극적으로 받아들이지 않는 게 놀랍다

  • 여러 업체가 과거에 이 버그를 겪었음: https://www.kb.cert.org/vuls/id/347067
    CVE-2023-4481(Juniper), CVE-2023-38802(FRR), CVE-2023-38283(OpenBGPd), CVE-2023-40457(EXOS)가 있었음
    당시 Arista는 영향을 받지 않았음

  • 인터넷 배관만큼 규모도 크고 우발적 복잡성도 비잔틴식으로 얽힌 것이 있었나 싶음

답변달기