▲

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

 (blog.benjojo.co.uk)
1P by GN⁺ 7일전 | ★ favorite | 댓글 1개
  • BGP 메시지 처리 버그로 인해 2025년 5월 20일 대규모 라우팅 불안정성 및 일부 네트워크의 인터넷 연결 단절 현상 발생
  • 문제의 원인은 잘못된 BGP Prefix-SID Attribute였으며, 주요 BGP 구현체(특히 JunOS와 Arista EOS)에서 예외적 반응 유발
  • Hutchison 및 Starcloud를 포함한 일부 트랜짓 캐리어가 원인 메시지를 중계하며 피해 확산
  • 사건으로 인해 약 100개 이상의 네트워크에서 대량의 BGP 세션 리셋 및 불안정성 발생
  • 벤더별 BGP 오류 내성 처리의 허점과 개선 필요성이 이번 사태를 통해 강조됨

May 27 2025

BGP 처리 버그로 인한 전세계 인터넷 라우팅 불안정성

2025년 5월 20일 화요일 오전 7시(UTC)에 BGP 메시지가 전파되면서, 인터넷 트래픽을 처리하는 데 자주 사용되는 두 가지 주요 BGP 구현체에서 예기치 못한 동작 현상 발생

이로 인해 다수의 ‘인터넷 연결 BGP 세션’이 자동으로 종료되는 현상으로 최소한의 라우팅 불안정성에서 최악의 경우 일부 네트워크의 연결 단절까지 일시적으로 발생함

문제의 BGP 메시지

  • bgp.tools에서 수집된 세션을 분석한 결과, 이 현상을 일으킨 BGP Update 메시지는 평범해 보이나, 내부 데이터가 0x00으로 채워진 손상된 BGP Prefix-SID Attribute를 포함함
  • 대부분의 BGP 구현체(IOS-XR, Nokia SR-OS)는 RFC7606(BGP 오류 내성)에 따라 올바르게 필터링하지만, JunOS와 Arista EOS 간 상호작용에서 문제 발생
    • JunOS는 손상된 메시지를 유지해 전달하고, Arista EOS는 해당 메시지를 수신하면 BGP 세션을 재설정함
  • Juniper 하드웨어(JunOS)가 많이 쓰이는 환경에서, Arista EOS와 연결된 경우 최장 10분가량 인터넷 접속 단절 현상 발생 가능성 있음

문제의 메시지 발신자

  • 해당 기간 bgp.tools 아카이브를 분석해보면 여러 AS 오리진이 관련되어 있음

  • 이는 Prefix를 생성한 네트워크가 아닌, 이동 경로 중간의 트랜짓 캐리어가 잘못된 Attribute를 추가했음을 시사함

  • 문제 발생에 연관된 주요 AS는 다음과 같음

    • AS9304 (Hutchison Global Communications Limited)
    • AS135338 (Starcloud Information Limited)
    • AS151326 (DCConnect Communication Pte. Ltd.)
    • AS138077 (PT Abhinawa Sumberdaya Asia)

  • bgp.tools 데이터로 볼 때 Attribute를 실제 추가한 쪽은 Starcloud(AS135338) 혹은 Hutchison(AS9304) 일 가능성 높음

  • 해당 Attribute가 전파된 대표적 Prefix들은 156.230.0.0/16, 138.113.116.0/24 등임

  • Hutchison/AS9304가 다수의 인터넷 익스체인지(IX)에 연결되어 있으면서, bird가 사용하는 라우트 서버에도 메시지가 전파됨

  • Bird는 BGP SID를 지원하지 않아 필터링 없이 수많은 IX로 메시지를 전송, 망 규모의 혼란이 학대됨

BGP Prefix-SID란?

  • BGP Prefix-SID Attribute는 일반적으로 내부 BGP 세션에서만 사용되어야 하며, 하나의 네트워크 내에서 목적지로 이동하는 경로를 정의하는 데 쓰임(RFC8669)
  • 해당 Attribute가 글로벌 라우팅 테이블로 누출된 원인은, 외부 BGP 세션이 내부 세션처럼 구성된 경우일 수 있음

피해 대상

  • 정확한 피해자 식별은 어렵지만, 초기 BGP 메시지 이후 엄청난 변동(churn)을 보인 약 100여 개 네트워크에서 문제 확인
  • 평소 bgp.tools의 라우트 콜렉터는 초당 2~3만 메시지를 수집하지만, 사건 시점엔 10초 평균 15만건 이상 기록
  • 이 수치는 광범위한 인터넷 경로에 심각한 장애가 발생했다는 신호임

벤더의 책임과 시사점

  • 근본 원인이 확실하지 않지만, 인터넷 규모로 오류 메시지가 확산된 점에서 기존의 BGP 오류 처리 문제가 현실적 위험임을 입증함
  • 타 벤더는 문제 Attribute를 필터링했으나, Juniper는 이를 우회적으로 허용해 Arista 장비에 전달, BGP 오류 내성 코드의 미비로 세션 리셋 유발
  • JunOS의 공식 문서에서도 “메시지 전체를 점검하지는 않는다”는 사실을 명시함
  • 이러한 설계로, JunOS는 원격 세션 리셋 위험은 방지하나, 다른 피어 혹은 고객에게 문제 메시지 전달 가능성 존재

결론

  • 이번 사건은 장애가 단기간이었지만, 규모 확장 시 더 심각해질 가능성이 있음을 시사함

  • 서비스가 점점 IP 중심으로 이동함에 따라, 인터넷 장애의 영향은 단순 소비자 메일 접속 불가를 넘어, TV 방송 실패, 긴급 서비스 콜 불통 등으로 확산될 위험 존재

  • 이로 인해 현실적으로 실제 인명 피해까지 발생할 가능성 있다는 점에서, 벤더별 확실한 BGP 오류 내성 구현 필요성 강조됨

  • bgp.tools 데이터 분석에 협력할 네트워크 운영자의 참여 가능성이 안내됨 (링크 제공)

▲
GN⁺ 7일전  [-]
Hacker News 의견

  • 일반적으로 "받을 때는 관대하게, 내보낼 때는 구체적으로"라는 원칙이 표준적인 접근 방식으로 알려져 있는 내용임

    • 깨진 메시지를 걸러내거나(drop, 필터), 속성만 무시하고 전달하거나(break), 연결 자체를 끊는(Arista처럼) 선택지들이 존재함

    • 나는 네 번째(Arista 방식)가 진짜 용납하기 힘든 동작이라 생각함

    • 세 번째(Juniper)도 바람직하진 않지만 치명적인 문제라고 볼 순 없다는 생각임

    • 편집: 내용을 다시 읽어보니 Arista가 네 번째가 아니라 두 번째(연결 종료)였음

    • 연결을 아예 무효로 보고 닫아버린 것뿐인데, 이건 사용자 경험을 생각하면 그리 좋은 결정은 아니나 받아들일 수준이라는 인상임

    • 이미 RFC 7606(BGP UPDATE 메시지의 개선된 에러 처리)이 존재하고, 여기서 깨진 메시지를 어떻게 처리할지 구체적으로 명시해둔 상태임

      • 가장 흔한 방법은 'treat-as-withdraw'(마치 경로를 withdraw한 것처럼 처리)임
      • 깨진 메시지를 그냥 무시해버리면 이전 상태가 실제로는 유효하지 않음에도 그대로 유지되는 문제가 생김

    • "관대하게 받아들이고 구체적으로 내보내라"는 원칙은 바로 이른바 "robustness principle" 또는 "Postel's law"라고 부르는 것임

      • 이 원칙은 1980~90년대 인터넷의 초창기에서 온 개념임
      • 하지만 지금은 이게 잘못된 사고방식이었다는 걸 업계가 널리 인식 중임
      • 해당 원칙 때문에 프로토콜 경직화와 셀 수 없는 보안문제가 야기됨

    • BGP의 동작특성을 악용해서, 로컬 장비가 모르는 속성을 그대로 전달할 수 있음을 이용한 다양한 일이 네트워크 전반에서 벌어졌던 문제점이 있었음

      • 이제는 이런 "기능"의 단점이 드러나는 현실을 경험하고 있음

    • 작성자도 관련 글에서 이런 점을 지적함

      • 이 "기능"은 시스템이 이해하지 못하는 데이터를 무비판적으로 전달하게 되어 의외로 굉장히 나쁜 아이디어로 보임
      • 하지만 이 기능 덕분에 Large Communities와 같은 신기능이 빠르게 확산될 수 있었고, 새로운 BGP 기능들의 도입이 가능했던 측면이 존재함

    • 나는 이 접근 방법에 동의하지 않음

      • 무엇을 받아들일지, 무엇을 내보낼지 둘 다 엄격하게 구체적으로 하는 것이 훨씬 좋다고 생각함

  • CVE-2023-4481 버그를 네트워크 전반에 패치하느라 미친 듯이 분주하게 움직였던 기억이 아직도 있음

    • 이 종류의 버그는 앞으로도 다루기 정말 악몽 같은 존재임
    • BGP의 설계와 구현 방식 특성상, 이런 동작들을 고치는 데 상당히 오랜 시간이 걸릴 것이라는 걱정임

  • 과거 통신장비 업체에서 BGP 기능을 개발했었던 경험이 있음(꽤 오래 전 이야기임)

    • 아직도 BGP가 너무 복잡하다고 생각함

    • 사람들은 계속 새로운 기능을 추가하고, 벤더는 표준이나 드래프트에 맞춰 구현을 반복함

    • 영원히 퇴출되지 않을 것만 같은 BGP의 특성상 이런 버그가 끊임없이 재발할 듯한 느낌임

      • 예전에는 AT&T 같은 사업자와 Juniper, Cisco 등의 벤더들이 MPLS, VPN 관련 기능에 BGP를 밀어붙이며 시스템이 깊은 복잡성에 빠지기도 했었음
        • 지나치게 복잡했지만 일부는 그것으로 돈을 많이 벌었음

  • HGC Global Communications Limited(Hutchison Global Communications Limited에서 이름 변경, 약칭 HGC)는 홍콩의 인터넷 서비스 제공업체임

  • BGP가 이런 사안들에 대해 여러 하드웨어 벤더들이 표준을 맞춘다면 훨씬 더 안정적일 것처럼 느껴짐

    • 실제 문제는 각 벤더가 자사에 고객을 묶어놓기(락인) 위해 표준화를 꺼리는 것에 있는 건지 궁금증이 있음
    • 참고로 내 BGP 이해도는 얕은 수준임을 미리 밝힘

  • 나만 그런 건지 모르겠는데, BGP란 걸 뭔가 문제를 일으켰다는 얘기를 듣기 전까진 들어본 적도 없음

    • TCP/IP처럼 인터넷에서 필수적인 프로토콜이지만, TCP/IP는 학교, 커리어, 책 등에서 많이 배웠던 반면, BGP는 한 번도 다뤄보지 못했음
    • 집에서 TCP/IP로 실습도 해보고 학습할 수 있는데, BGP는 어떻게 '집에서 놀아볼' 수 있는지 전혀 모르겠음

      • 집에서 BGP를 실습해보려면 어떤 방법이 있다면 궁금함

      • BGP 구현이 탑재된 실제 라우터(저렴한 것 중엔 Mikrotik 같은 장비), 또는 오픈 소스 구현체를 구입해서 해볼 수 있는 것임

        • 글에 나온 bird, 매우 인기있는 FRR(Free Range Routing) 등이 있음
        • 도커 컨테이너 두 개를 띄우고 BGP 세션을 맺어서 static route 등을 전파해볼 수 있음
        • 튜토리얼을 원하면 이 링크의 가이드가 무료 소프트웨어 기반으로 따라할 수 있게 잘 정리돼 있음

      • DN42는 라우팅 기술을 실습할 수 있는 놀이터임

        • 다만 시간 투자가 필수라 가볍게 도전할 수 있는 건 아님
        • 나 역시 네트워킹을 꽤 다루지만 WAN 라우팅은 여전히 헷갈림
        • GNS3가 어떤 네트워킹 테크놀로지든 직접 실습하기 가장 쉬움
        • DN42 위키

      • 내 학부 네트워크 과목에서는 BGP를 다뤄주지 않았지만, 대학원 수업에선 BGP를 배웠음

        • 여러 AS를 시뮬레이션할 수 있는 파이썬 패키지를 썼었는데 정확한 패키지 이름은 기억나지 않음

      • 내가 들었던 학부 네트워크 수업에서는 BGP를 칠판 위에서 간단히 언급만 했음

        • BGP 실습용으로는 저자가 사용한 것처럼 네트워크 시뮬레이터를 활용할 수 있음
        • 우리 수업에선 gini라는 시뮬레이터를 썼는데, 교수님 대학원생이 만든 프로그램이었음
        • 저자가 쓴 gns3는 cisco 특화된 ns3 느낌임
        • ns3는 배울 게 많아 어렵게 느껴졌음
        • gini는 좀 더 쉬운 인터페이스지만 성능은 떨어지는 편임
        • gini 프로젝트 안내
        • gns3 공식문서

      • 실제 인터넷 트래픽에 연결된 대규모 네트워크를 관리해야만 제대로 BGP를 '실습'할 수 있는 느낌임

        • 집에서 만져볼 수 있는 건 네트워크 시뮬레이터를 쓰는 것뿐임

  • 과거 여러 벤더들도 본문과 유사한 버그가 있었음

    • 관련 보안 취약점 정보
    • CVE-2023-4481(Juniper), CVE-2023-38802(FRR), CVE-2023-38283(OpenBGPd), CVE-2023-40457(EXOS) 등
    • Arista는 그때 영향이 없었던 업체임

  • 우리 IOS XR 섀시 장비에서도 비슷한 패킷을 받은 적이 있음

    • 이와 동시에 BGP 경로 광고가 많았던 경험이 있음

    • upstream 장비가 뭔지 정확히 모르겠음

    • BGP 프로토콜이 제대로 퍼징되어 테스트되는지 궁금증이 생김

    • 워낙 중요한 프로토콜이라 일부러 장애를 내볼 엄두가 안 나서 그런 건지도 생각함

    • BGP용 퍼저는 작성하기 쉽겠지만, 크래시 진단이 너무 어려울 수 있음

      • (글 작성자)
        • 네, 바로 이 점을 제가 포스팅에서 실제로 해봄
        • 관련 포스트

  • 인터넷 백본만큼 방대하고 우발적 복잡성이 쌓인 시스템이 또 있었는지 의문을 품게 됨

  • 이런 버그의 영향력을 감안하면 상호운용성 테스트 스위트 같은 것을 운영하는 컨소시엄이 있을 줄 알았지만 놀라움

    • 아니면 정말로 있지만 이 문제가 테스트 범위에서 빠졌다는 뜻일지도
    • 모두 가능한 패킷 에러를 자동생성해서 커버리지 높이게 fuzzer나 머신으로 다양하게 테스트케이스를 만드는 것이 당연해보이는데
    • 러닝 시간이 며칠이든 상관없을 정도
    • 본문 저자는 실제로 fuzzer를 만들어서 사용했고, 비슷한 문제를 여러 번 만났음
    • 이런 중요한 연구들에 대해 벤더들이 적극적으로 관심 두지 않는 점이 신기하게 느껴짐
답변달기