pile·
네트워크·cloudflare-blogCloudflare Blog·

BGP ORIGIN 속성 조작이 인터넷 라우팅에 미치는 영향

BGP(Border Gateway Protocol)의 ORIGIN 속성이 인터넷 라우팅 결정에 어떻게 조작되는지 Cloudflare가 실험을 통해 분석했다. RFC는 원점 AS가 설정한 ORIGIN 값을 다른 라우터가 변경해서는 안 된다고 규정하지만, 관측된 경로의 약 70%가 원래 값과 다른 ORIGIN을 갖고 있다는 것이 밝혀졌다. 이 조작은 트래픽과 수익을 자사 네트워크로 끌어들이려는 상위 계층 ISP들의 수익 추구 행동에서 비롯된다.

핵심 포인트
  • BGP ORIGIN 속성은 IGP(0)/EGP(1)/INCOMPLETE(2) 세 값을 가지며, 낮은 값일수록 경로 선택에서 우선순위가 높다.
  • Cloudflare 실험에서 전체 IPv4 AS_PATH의 70%, IPv6의 67%가 원래 설정된 ORIGIN과 다른 값을 보였다.
  • 직접 피어 중 약 10%가 ORIGIN을 IGP로 바꿔 더 많은 트래픽을 자사 링크로 유인했다.
  • 상위 50개 AS 중 26%가 ORIGIN 조작을 수행하며, 조작 AS의 20.3%가 AS Rank 상위 50위 안에 포함된다.
  • ORIGIN 조작으로 EGP 프리픽스 기준 IPv4는 18%, IPv6는 40%의 추가 경로를 확보했다.
  • Cloudflare는 이 속성이 현대 인터넷에서 의미 있는 역할을 하지 못한다고 보고, 모든 BGP 구현체가 ORIGIN을 IGP로 표준화할 것을 제안한다.
상세 정리
  • 배경: ORIGIN 속성은 경로가 BGP에 어떻게 주입됐는지를 나타내며, Local Preference와 AS_PATH 길이가 동일할 때 값이 낮을수록 경로 선택 우선순위가 높다.
  • RFC 규정 위반: RFC4271은 ORIGIN을 원점 AS 외에는 변경하지 말 것을 SHOULD NOT 수준으로 권고하지만 강제 규정이 아니라 실제로 광범위하게 위반된다.
  • 수익 구조: Transit ISP가 ORIGIN을 IGP로 바꾸면 경쟁 ISP보다 경로 선택에서 우위를 점해 더 많은 트래픽과 요금 수입을 확보할 수 있다.
  • 실험 설계: 모든 피어링 위치에서 IGP/EGP/INCOMPLETE 세 값으로 IPv4·IPv6 프리픽스 각 3개씩 발표 후 철회해 경로 사냥을 유발했고, RIPE RIS와 RouteViews의 MRT 덤프를 BGPKIT으로 파싱했다.
  • 2홉 경로 분석: 직접 피어 352개(IPv4) 중 약 10%가 ORIGIN을 IGP로 조작했으며, Tier-1 16개 중 6개가 포함됐다.
  • 장경로 분석 알고리즘: Cloudflare를 신뢰 집합 시드로 놓고 반복 추론으로 관측된 AS의 75.6%를 추적했고, 그 중 10.6%가 ORIGIN 변경자였다.
  • 조작 AS의 중심성: AS Rank 상위 50개 중 26%, 상위 100개 중 20%가 조작 수행자로, 개수는 적지만 인터넷 트래픽에 미치는 영향이 크다.
  • 트래픽 우회 효과: IPv4에서 12개(18%), IPv6에서 33개(40%)의 경로가 ORIGIN 조작으로 Tier-1 네트워크를 통해 우회됐다.
  • 군비경쟁 구조: 경쟁 ISP들이 수익 보호를 위해 ORIGIN 조작을 시작하면 다른 ISP들도 방어적으로 조작에 나서는 악순환이 발생한다.
  • 폐기 제안: IETF의 만료된 드래프트 "Scrubbing BGP ORIGIN Attribute"를 부활하거나 새 접근으로, 모든 BGP 구현체가 수신·발신 경로의 ORIGIN을 IGP로 설정하도록 표준화하는 방향을 제안한다.
왜 읽나BGP 라우팅 보안과 인터넷 아키텍처에 관심 있는 네트워크 엔지니어와 ISP 운영자가 ORIGIN 조작의 실태와 영향을 실험 데이터 기반으로 파악할 수 있다.
cloudflare-blog
Cloudflare Blog 블로그
원문은 여기서 이어서 읽을 수 있어요
원문 읽기
읽음 (0)

이 글과 비슷한

  1. 네트워크·cloudflare-blogCloudflare Blog·

    Cloudflare Cache Response Rules — 오리진 응답 기반 캐시 제어

    Cloudflare가 오리진 응답이 도착한 뒤 캐시에 쓰이기 직전에 개입하는 Cache Response Rules를 내놨다. 기존 Cache Rules는 요청 단계에서만 동작해, 오리진이 붙인 Set-Cookie·no-cache·ETag 때문에 충분히 캐시 가능한 응답이 오리진으로 되돌아가는 문제를 풀지 못했다. 새 규칙은 응답 헤더를 보고 헤더 제거·캐시 태그 관리·Cache-Control 수정을 수행해, 오리진 수정 없이 캐시 적중률을 끌어올린다.

  2. 네트워크·cloudflare-blogCloudflare Blog·

    Cloudflare Internal DNS 정식 출시 — 사설·공인 DNS 통합 구조

    Cloudflare가 사설(내부)·공인 DNS 해석을 하나의 플랫폼으로 통합하는 Internal DNS를 정식 출시했다. 기존에는 공인 DNS·내부 DNS·클라우드별 DNS가 제각기 다른 보안 정책으로 흩어져 공통 컨트롤 플레인이 없었고, split-horizon 구성은 병렬 시스템을 수동 동기화하다 drift로 장애를 냈다. 새 제품은 단일 API·감사 로그·정책 계층으로 이를 합치고, 1.1.1.1 인프라 위에서 하드웨어 없이 동작하며 Enterprise는 Gateway에 무료 포함된다.

  3. 네트워크·NHN Cloud MeetupNHN Cloud·

    경계가 만든 길, Load Balancer(DSR)

    NHN Cloud가 XDP/eBPF 기반 커널 단 기술로 만든 DSR(Direct Server Return) 방식 로드 밸런서를 소개한다. 기존 프록시 방식 LB는 요청·응답을 모두 종단·중계해 응답 트래픽이 클수록 LB가 병목이 된다. 이를 요청만 LB를 경유하고 응답은 서버가 클라이언트에 직접 보내는 비대칭 구조로 해결한다. 미디어 스트리밍·대용량 다운로드·게임 서버처럼 응답이 큰 L4 워크로드가 대상이다.