Cloudflare는 BGP 프로토콜의 라우팅 누수를 제한하는 데 사용되는 RFC 9234 표준의 확산 정도에 대한 분석을 발표했다. 이 분석은 자사 네트워크와의 교환 세션 데이터와 인터넷을 통해 테스트 경로를 발표한 실험을 바탕으로 했다. 이 회사는 67개 네트워크가 직접 전송하는 경로에 Only to Customer 또는 OTC 특성을 추가하고 있음을 확인했지만, 여러 네트워크가 경로를 전달하는 과정에서 이 특성을 제거한다는 사실도 발견했다. 이는 호환 네트워크가 누수를 탐지하고 거부하는 능력을 약화시킨다.
BGP 누수는 네트워크가 제공자 또는 피어로부터 학습한 경로를 인터넷 경로의 상업적 관계와 가정된 계층적 논리에 어긋나게 다른 제공자 또는 피어에게 광고할 때 발생한다. 이로 인해 데이터 트래픽이 이를 수용할 준비가 되어 있지 않거나 애초에 전달 권한이 없는 네트워크를 거쳐 이동할 수 있으며, 지연 시간 증가, 패킷 손실 또는 더 광범위한 장애가 발생할 가능성이 있다.
누수 방지 규칙을 프로토콜로 이전하기
기존 보호 메커니즘은 각 운영자가 프리픽스 필터와 IRR 레코드에서 추출한 정책 등을 수동으로 설정하도록 요구하며, 각 BGP 세션의 관계를 정확히 정의해야 한다. RFC 9234는 두 가지 구성 요소인 BGP Roles와 OTC 특성을 통해 이러한 부담의 일부를 프로토콜 자체로 이전할 것을 제안한다.
BGP Roles는 eBGP 세션에서 두 이웃 간의 관계를 정의한다. 예를 들어 Provider, Customer, Peer가 있으며, 인터넷 교환 지점의 라우트 서버와 관련된 RS 및 RS-Client도 포함된다. 양측이 호환되지 않는 역할을 전송하면 세션은 계속 유지되다가 나중에 실제 누수로 오류가 나타나는 대신 Role Mismatch 알림과 함께 거부된다. 부분적으로 도입된 경우에는 한쪽만 역할을 전송해도 세션이 작동할 수 있다. 다만 상대방이 어떤 역할도 광고하지 않는 세션을 거부하는 엄격 모드를 운영자가 활성화한 경우는 예외다.
OTC 특성은 경로가 계층 구조를 따라 위로 이동하는 것을 멈추고 고객에게 전달되기 시작할 때, 이를 처음 추가한 자율 시스템 번호를 기록한다. 일단 OTC가 존재하면 해당 경로는 제공자, 피어 또는 라우트 서버로 이동해서는 안 되며, 호환 라우터는 이를 허용하지 않는 관계에서 OTC를 포함한 경로가 도착하면 거부할 수 있다. 이에 따라 역할을 설정한 뒤에는 운영자가 각 세션마다 작성한 정책에 전적으로 의존하지 않고 방지를 자동화할 수 있다.
Cloudflare는 실제로 무엇을 측정했는가?
Cloudflare는 라우터의 BMP 데이터를 사용하고 3개월 동안 직접 이웃으로부터 수신한 OTC 값을 모니터링했다. 이 회사는 특성 값이 이웃의 자율 시스템 번호와 같을 때 해당 네트워크를 준수 후보로 간주했다. 이는 여러 네트워크를 거친 경로를 분석할 때 발생하는 혼동을 줄이는 방법이다. 측정 결과 OTC를 추가하는 자율 시스템은 67개로 나타났다. 다만 라우트 서버가 새로운 기능을 더 빠르게 도입할 수 있으며, 개인이 운영하는 일부 네트워크도 결과에서 눈에 띄는 비율로 나타났다는 점을 덧붙였다.
반면 RouteViews와 RIPE RIS의 공개 RIB 데이터를 분석한 결과는 더욱 보수적이었다. Cloudflare는 전송 시 OTC를 추가하는 네트워크와 수신 시 누락된 값을 채우는 네트워크를 구분하려고 시도한 뒤, 특성을 추가할 가능성이 있는 네트워크 18개와 특성을 채울 가능성이 있는 네트워크 20개를 확인했다. 직접 이웃의 결과를 합치면 RFC 9234를 준수할 가능성이 있는 네트워크는 36개였다. 이 회사는 제한된 수의 경로나 이웃을 보유한 네트워크가 이 방법론에서 누락될 수 있다고 강조한다.
OTC를 제거한 네트워크
Cloudflare는 자사 교환 지점에서 값 13335를 포함한 IPv4 프리픽스와 IPv6 프리픽스를 광고한 뒤, RIPE RIS와 RouteViews 데이터 및 자체 BMP 데이터를 사용해 광고와 철회 과정의 BGP 메시지를 분석함으로써 OTC의 전파를 시험했다. 첫 단계에서 이 회사는 특성을 제거하는 6개 자율 시스템을 확인했으며, 여기에는 1계층 네트워크인 GTT, AS3257과 Arelion, AS1299이 포함됐다. 더 긴 경로에 대한 분석을 계속한 결과 OTC를 제거하는 9개 네트워크가 추가로 확인됐다.
실험에서 IPv4의 AS_PATH 경로 중 33.1%, IPv6 경로 중 17%에서 특성이 사라졌다. OTC를 잃은 IPv4 경로의 96.6%와 IPv6 경로의 92.9%에는 GTT, Arelion 또는 두 네트워크가 모두 포함됐으며, 대부분의 사례는 Arelion이 차지했다. 다음 홉이 두 네트워크 중 하나였던 경로를 조사한 결과, Cloudflare는 GTT가 특성을 일관되게 제거하는 반면, 해당 표본에서 Arelion은 IPv4 경로의 71.4%와 IPv6 경로의 40.7%에서 특성을 제거한다는 사실을 확인했다.
Cloudflare는 두 네트워크가 OTC 제거가 BGP 오류 처리와 관련된 사건 이후 발생한 방어적 관행의 일부였음을 확인했다고 밝혔다. 발표된 결과에 따르면 GTT의 설정은 계속 특성을 제거했지만, Arelion은 Cloudflare와의 소통 이후 특성을 유지하기 시작했다. 이는 테스트 경로에 대한 후속 분석을 통해 확인됐다.
네트워크 운영자에게 실무적으로 무엇이 달라지는가?
이번 결과는 RFC 9234의 도입이 라우터의 기능 지원 여부뿐 아니라 중간 네트워크가 선택적으로 전달되는 특성을 계속 전달하는지 여부에도 달려 있음을 보여준다. 중앙에 위치한 네트워크가 OTC를 제거하면, 그 뒤에 여러 홉 떨어진 호환 네트워크가 방지할 수 있었던 누수를 탐지하지 못할 수 있다.
Cloudflare에 따르면 Junos OS와 Junos OS Evolved는 RFC 9234를 지원하며, Cisco IOS XR 지원은 26.4.1 버전에서 예정되어 있었다. 한편 Arista EOS, Nokia SR OS, Huawei, Extreme SLX-OS, RouterOS, BIRD, OpenBGPD, FRR, ArcOS, GoBGP 및 ExaBGP를 포함한 다른 구현은 지원 상태가 완전히 특정되지 않은 채 표에 포함됐다. 이 회사는 해당 기능을 사용할 수 있는 운영자에게 유지보수 시간대에 BGP Roles를 단계적으로 설정할 것을 권고한다. 적용하려면 BGP 세션을 재설정해야 하기 때문이다. Cloudflare는 또한 전 세계 자사 네트워크 전반에 설정을 단계적으로 배포하기 시작했으며, Cloudflare Radar의 라우팅 섹션에서 도입 데이터를 제공할 계획이다.