# BGP 처리 버그로 인해 인터넷 라우팅 불안정성 발생 > Clean Markdown view of GeekNews topic #21163. Use the original source for factual precision when an external source URL is present. ## Metadata - GeekNews HTML: [https://news.hada.io/topic?id=21163](https://news.hada.io/topic?id=21163) - GeekNews Markdown: [https://news.hada.io/topic/21163.md](https://news.hada.io/topic/21163.md) - Type: GN+ - Author: [neo](https://news.hada.io/@neo) - Published: 2025-05-29T10:03:05+09:00 - Updated: 2025-05-29T10:03:05+09:00 - Original source: [blog.benjojo.co.uk](https://blog.benjojo.co.uk/post/bgp-attr-40-junos-arista-session-reset-incident) - Points: 1 - Comments: 1 ## Topic Body - **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 오류 내성)](https://datatracker.ietf.org/doc/html/rfc7606)에 따라 올바르게 필터링하지만, 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](https://bird.network.cz/)가 사용하는 라우트 서버에도 메시지가 전파됨 - Bird는 BGP SID를 지원하지 않아 필터링 없이 수많은 IX로 메시지를 전송, 망 규모의 혼란이 학대됨 #### BGP Prefix-SID란? - **BGP Prefix-SID Attribute**는 일반적으로 내부 BGP 세션에서만 사용되어야 하며, 하나의 네트워크 내에서 목적지로 이동하는 경로를 정의하는 데 쓰임([RFC8669](https://datatracker.ietf.org/doc/rfc8669)) - 해당 Attribute가 글로벌 라우팅 테이블로 누출된 원인은, 외부 BGP 세션이 내부 세션처럼 구성된 경우일 수 있음 #### 피해 대상 - 정확한 피해자 식별은 어렵지만, **초기 BGP 메시지 이후 엄청난 변동(churn)을 보인 약 100여 개 네트워크**에서 문제 확인 - 평소 bgp.tools의 라우트 콜렉터는 초당 2~3만 메시지를 수집하지만, 사건 시점엔 10초 평균 15만건 이상 기록 - 이 수치는 광범위한 인터넷 경로에 **심각한 장애**가 발생했다는 신호임 #### 벤더의 책임과 시사점 - 근본 원인이 확실하지 않지만, 인터넷 규모로 오류 메시지가 확산된 점에서 [기존의 BGP 오류 처리 문제](https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling)가 현실적 위험임을 입증함 - 타 벤더는 문제 Attribute를 필터링했으나, **Juniper는 이를 우회적으로 허용**해 Arista 장비에 전달, BGP 오류 내성 코드의 미비로 세션 리셋 유발 - JunOS의 공식 문서에서도 “메시지 전체를 점검하지는 않는다”는 사실을 명시함 - 이러한 설계로, JunOS는 원격 세션 리셋 위험은 방지하나, **다른 피어 혹은 고객에게 문제 메시지 전달** 가능성 존재 #### 결론 - 이번 사건은 장애가 단기간이었지만, 규모 확장 시 더 심각해질 가능성이 있음을 시사함 - 서비스가 점점 IP 중심으로 이동함에 따라, 인터넷 장애의 영향은 단순 소비자 메일 접속 불가를 넘어, **TV 방송 실패**, **긴급 서비스 콜 불통** 등으로 확산될 위험 존재 - 이로 인해 현실적으로 **실제 인명 피해**까지 발생할 가능성 있다는 점에서, 벤더별 확실한 BGP 오류 내성 구현 필요성 강조됨 - bgp.tools 데이터 분석에 협력할 네트워크 운영자의 참여 가능성이 안내됨 (링크 제공) ## Comments ### Comment 39437 - Author: neo - Created: 2025-05-29T10:03:05+09:00 - Points: 1 ###### [Hacker News 의견](https://news.ycombinator.com/item?id=44105796) - 일반적으로 "받을 때는 관대하게, 내보낼 때는 구체적으로"라는 원칙이 표준적인 접근 방식으로 알려져 있는 내용임 - 깨진 메시지를 걸러내거나(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)는 홍콩의 인터넷 서비스 제공업체임 - [해당 위키피디아 페이지](https://en.wikipedia.org/wiki/HGC_Global_Communications) 참고 - BGP가 이런 사안들에 대해 여러 하드웨어 벤더들이 표준을 맞춘다면 훨씬 더 안정적일 것처럼 느껴짐 - 실제 문제는 각 벤더가 자사에 고객을 묶어놓기(락인) 위해 표준화를 꺼리는 것에 있는 건지 궁금증이 있음 - 참고로 내 BGP 이해도는 얕은 수준임을 미리 밝힘 - 나만 그런 건지 모르겠는데, BGP란 걸 뭔가 문제를 일으켰다는 얘기를 듣기 전까진 들어본 적도 없음 - TCP/IP처럼 인터넷에서 필수적인 프로토콜이지만, TCP/IP는 학교, 커리어, 책 등에서 많이 배웠던 반면, BGP는 한 번도 다뤄보지 못했음 - 집에서 TCP/IP로 실습도 해보고 학습할 수 있는데, BGP는 어떻게 '집에서 놀아볼' 수 있는지 전혀 모르겠음 - 집에서 BGP를 실습해보려면 어떤 방법이 있다면 궁금함 - BGP 구현이 탑재된 실제 라우터(저렴한 것 중엔 Mikrotik 같은 장비), 또는 오픈 소스 구현체를 구입해서 해볼 수 있는 것임 - 글에 나온 bird, 매우 인기있는 FRR(Free Range Routing) 등이 있음 - 도커 컨테이너 두 개를 띄우고 BGP 세션을 맺어서 static route 등을 전파해볼 수 있음 - 튜토리얼을 원하면 [이 링크](https://blog.ipspace.net/2023/08/bgp-labs-basic-setup/)의 가이드가 무료 소프트웨어 기반으로 따라할 수 있게 잘 정리돼 있음 - DN42는 라우팅 기술을 실습할 수 있는 놀이터임 - 다만 시간 투자가 필수라 가볍게 도전할 수 있는 건 아님 - 나 역시 네트워킹을 꽤 다루지만 WAN 라우팅은 여전히 헷갈림 - GNS3가 어떤 네트워킹 테크놀로지든 직접 실습하기 가장 쉬움 - [DN42 위키](https://wiki.dn42.us/home) - 내 학부 네트워크 과목에서는 BGP를 다뤄주지 않았지만, 대학원 수업에선 BGP를 배웠음 - 여러 AS를 시뮬레이션할 수 있는 파이썬 패키지를 썼었는데 정확한 패키지 이름은 기억나지 않음 - 내가 들었던 학부 네트워크 수업에서는 BGP를 칠판 위에서 간단히 언급만 했음 - BGP 실습용으로는 저자가 사용한 것처럼 네트워크 시뮬레이터를 활용할 수 있음 - 우리 수업에선 gini라는 시뮬레이터를 썼는데, 교수님 대학원생이 만든 프로그램이었음 - 저자가 쓴 gns3는 cisco 특화된 ns3 느낌임 - ns3는 배울 게 많아 어렵게 느껴졌음 - gini는 좀 더 쉬운 인터페이스지만 성능은 떨어지는 편임 - [gini 프로젝트 안내](https://citelab.github.io/gini5/) - [gns3 공식문서](https://docs.gns3.com/docs/) - 실제 인터넷 트래픽에 연결된 대규모 네트워크를 관리해야만 제대로 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는 그때 영향이 없었던 업체임 - 우리 IOS XR 섀시 장비에서도 비슷한 패킷을 받은 적이 있음 - 이와 동시에 BGP 경로 광고가 많았던 경험이 있음 - upstream 장비가 뭔지 정확히 모르겠음 - BGP 프로토콜이 제대로 퍼징되어 테스트되는지 궁금증이 생김 - 워낙 중요한 프로토콜이라 일부러 장애를 내볼 엄두가 안 나서 그런 건지도 생각함 - BGP용 퍼저는 작성하기 쉽겠지만, 크래시 진단이 너무 어려울 수 있음 - (글 작성자) - 네, 바로 이 점을 제가 포스팅에서 실제로 해봄 - [관련 포스트](https://blog.benjojo.co.uk/post/bgp-path-attributes-grave-error-handling) - 인터넷 백본만큼 방대하고 우발적 복잡성이 쌓인 시스템이 또 있었는지 의문을 품게 됨 - 이런 버그의 영향력을 감안하면 상호운용성 테스트 스위트 같은 것을 운영하는 컨소시엄이 있을 줄 알았지만 놀라움 - 아니면 정말로 있지만 이 문제가 테스트 범위에서 빠졌다는 뜻일지도 - 모두 가능한 패킷 에러를 자동생성해서 커버리지 높이게 fuzzer나 머신으로 다양하게 테스트케이스를 만드는 것이 당연해보이는데 - 러닝 시간이 며칠이든 상관없을 정도 - 본문 저자는 실제로 fuzzer를 만들어서 사용했고, 비슷한 문제를 여러 번 만났음 - 이런 중요한 연구들에 대해 벤더들이 적극적으로 관심 두지 않는 점이 신기하게 느껴짐