요약

  • Cloudflare는 2024년 6월 27일 두 건의 서로 다른 라우팅 사건을 보고했습니다. AS267613이 더 구체적인 경로1.1.1.1/32를 출처 발표하기 시작했고, AS262504는1.1.1.0/24를 상위인 AS1031로 유출했습니다. 두 사건은 같은 리졸버 주소에 영향을 미쳤지만, 동일한 발표, 경로 또는 제어 실패가 아니었습니다 [1].

  • 해당/32는 Cloudflare의 정상적인/24발표보다 더 구체적이었습니다. Cloudflare는 출처와 프리픽스 길이가 RPKI 무효이며 디폴트프리 존에 부적합함에도 여러 네트워크가 이를 전송에 사용했다고 밝혔습니다. 어느 티어원 제공자가 이를 원격 트리거 블랙홀 경로로 수용한 것으로 알려졌으며, 그 결과 해당 제공자의 다운스트림 네트워크에서 오는 트래픽이 폐기되었습니다 [1].

  • 유출된/24는 서로 다른 검증 문제를 드러냈습니다. 그 경로는 여전히 Cloudflare AS13335에서 끝났기 때문에, 고객-제공자 및 피어 전파 경로가 무단이었음에도 경로 출처 검증은 출처를 유효한 것으로 간주할 수 있었습니다. 유효한 ROA가 모든 중간 AS 관계를 승인하는 것은 아닙니다 [1][2][6][9].

  • Cloudflare는 20:03 UTC에 내부 인시던트를 발생시키고, AS267613과의 두 피어링 지점을 비활성화하고, 명시된 네트워크에 연락했으며, 6월 28일 02:28 UTC에/24유출이 완전히 해소된 것을 관측했다고 밝혔습니다. 보고된 사용자 영향은 1.1.1.1에 도달할 수 없거나 높은 지연이 발생하는 것이었습니다. Cloudflare는 또한 예시 그래프의 트래픽이 해당 출처 국가의 전체 요청 중 상대적으로 작은 비중을 나타낼 수 있다고 주의했습니다 [1].

  • APNIC의 독립 논평은 이 사건이 전 세계적으로 가시적이지 않았으며 전체 인터넷 사용자 기반 대비 미미했을 가능성이 높다고 밝혔지만, 여전히 많은 사용자에게 영향을 미쳤을 수 있다고 보았습니다. Internet Society Pulse는 더 넓은 관측 범위를 보고했습니다. 이러한 설명은 귀속된 상태로 유지되어야 하며, 근거 없는 전 세계 장애 주장으로 결합되어서는 안 됩니다 [2][3].

  • APNIC의 할당 기록과 Cloudflare의 ROA는 주소 블록과 승인된 출처에 관한 중요한 근거를 제공합니다. 그러나 이러한 기록은 다른 네트워크의 임포트 필터를 프로그래밍하지 않습니다. 운영 연속성은 출처 네트워크, 고객, 경로 서버, 트랜짓 제공자, 블랙홀 시스템이 실제로 강제하는 정책에 달려 있습니다 [4][5][6].

  • RFC 4271, RFC 7908, RFC 6811, RFC 8893, RFC 7454, RFC 8212는 BGP, 경로 유출, 출처 검증 및 필터링의 맥락을 정의합니다. RFC 9234는 관계 인식 Roles와 Only-to-Customer 속성을 추가합니다. RFC 7999와 RFC 3882는 블랙홀 신호 전달과 원격 트리거 블랙홀링을 설명합니다. 이 문서들은 이용 가능한 제어를 설명할 뿐, 관련된 모든 네트워크가 그것을 배치했다는 증명이 아닙니다 [7]-[15].

  • RouteViews와 RIPE RIS는 전파를 재구성하는 데 도움이 된 공개 관측을 보존했습니다. 수집기는 증거 시스템이지 라우팅 권위가 아닙니다. 책임성 시험은 어느 당사자가 각 경로를 예방, 거부, 탐지, 격리 또는 취소할 수 있었는지, 그리고 그 제어가 작동했다는 기록이 무엇인지입니다 [16][17].

하나의 주소가 여러 개의 서로 다른 제어 평면을 노출했다

1.1.1.1의 시각적 단순함은 독립적인 결정들의 연쇄를 감춥니다. 사용자가 하나의 주소를 입력하거나 구성합니다. 로컬 장치가 패킷을 보냅니다. 네트워크가 경로를 선택합니다. 트랜짓 제공자들이 대안을 비교합니다. 경로 서버가 발표를 배포합니다. Cloudflare의 애니캐스트 사이트가 도달 가능성을 광고합니다. 레지스트리가 번호 자원 정보를 기록하고, RPKI는 프리픽스를 승인된 출처에 결합할 수 있습니다. 각 단계는 서로 다른 질문에 답합니다.

이 사건이 중요한 이유는 두 개의 나쁜 경로가 그 연쇄를 서로 다른 방식으로 영향을 미칠 수 있었기 때문입니다. 하나는 단일 주소에 대한 출처 발표였습니다. 다른 하나는 이를 덮는/24의 유출이었습니다. 첫 번째는 출처 및 프리픽스 길이 승인과 블랙홀 제어를 시험했습니다. 두 번째는 경로가 AS 경로 끝에서 Cloudflare의 출처를 유지했음에도 관계 인식 익스포트와 고객 경로 필터링을 시험했습니다 [1].

이러한 사건들을 "BGP가 실패했다"는 일반적 주장으로 축소하면 책임을 배정하는 데 필요한 근거가 사라집니다. BGP는 구성된 스피커와 정책이 지시한 대로 작동했습니다: 경로 정보를 배포하고, 속성을 비교하고, 경로를 선택했습니다. 책임성 실패는 어느 경로가 출처 발표되었는지, 어느 것이 고객이나 피어로부터 수용되었는지, 어느 것이 이후 익스포트되었는지, 어느 방어적 신호 규칙이 트래픽 폐기를 허용했는지에 있었습니다.

같은 구분이 두 번째 오류도 방지합니다. 주소 할당이나 ROA는 자원과 그 승인된 출처에 관한 근거를 확립할 수 있지만, 어느 기록도 모든 라우터에 도달하지 않습니다. 네트워크는 검증 데이터를 가져오고, 경로를 분류하고, 그 분류를 정책에 연결하고, 무효한 발표를 거부하거나 선호도를 낮추어야 합니다. 경로 서버나 트랜짓 제공자도 경로가 수신된 상업적 또는 운영 관계를 이해해야 합니다. 기록은 그러한 결정을 지지합니다; 실행 중인 정책이 그것을 현실로 만듭니다.

공개 리졸버의 경우 그 결과는 유난히 가시적입니다. DNS 쿼리는 종종 애플리케이션 세션의 첫 번째 의존성입니다. 클라이언트가 구성된 리졸버에 도달할 수 없으면 브라우저는 많은 무관한 이름과 서비스를 이용할 수 없다고 보고할 수 있습니다. 그렇다고 모든 목적지의 권위 DNS가 실패한 것은 아닙니다. 하나의 재귀 리졸버 주소에 대한 접근이 손상된 것입니다. 따라서 정확한 언어가 필수적입니다: 이것은 1.1.1.1에 영향을 미친 도달 가능성 사고였으며, 글로벌 DNS 네임스페이스가 작동을 멈췄다는 증거가 아니었습니다.

공개된 연대기는 두 사건을 분리해 둡니다

Cloudflare가 공개한 타임라인은 6월 27일 18:51 UTC에 시작됩니다. 이때 AS267613이 자신을 출처로 하여1.1.1.1/32를 피어, 제공자, 고객에게 발표하기 시작했습니다. 1분 후 Cloudflare에 따르면 AS262504가 AS267613을 통해 수신한1.1.1.0/24를 상위인 AS1031로 유출했습니다. 공개된 경로는1031 262504 267613 13335였습니다. Cloudflare에 따르면 AS1031은 이어서/24를 인터넷 익스체인지 피어와 경로 서버에 전파했습니다 [1].

같은 18:52 시점에 Cloudflare에 따르면 어느 티어원 제공자가 AS267613으로부터/32를 RTBH 경로로 수신했습니다. 그 제공자의 경로를 사용해 1.1.1.1로 향하는 트래픽은 폐기되었습니다. 이는 유출된/24와 별개의 인과 경로입니다: 제공자는 호스트 경로를 폐기 지시로 취급했고, 다른 네트워크들은 유출된 AS 경로를 통해 이를 덮는 프리픽스를 학습했습니다 [1].

Cloudflare는 여러 국가의 도달 가능성 보고 이후 20:03에 내부 인시던트를 발생시켰습니다. 20:08에는/24에 대한 트래픽을 수신하던 AS267613과의 파트너 피어링 위치를 비활성화하고 AS267613에 연락했습니다. 20:10에 Cloudflare는/24의 새로운 유출 경로를 관측했습니다; 그 경로를 따르는 트래픽은 Cloudflare에 도달했지만 높은 지연을 겪었습니다. 20:17에는 상위 유출에 대해 AS262504에 연락했습니다 [1].

대응은 첫 번째 격리를 넘어 계속되었습니다. Cloudflare에 따르면 21:56에 브라질 외부 출처에서 프리픽스에 대한 트래픽을 수신하던 두 번째 AS267613 피어링 지점을 비활성화했습니다. 22:16에 또 다른/24유출이 상당량의 트래픽을 상파울루의 Cloudflare 피어링 지점으로 끌었습니다. 이때쯤 호스트 경로 하이재킹과 블랙홀링은 해소된 것으로 보였지만, 일부 쿼리는 여전히 높은 지연으로 반환되었습니다. Cloudflare는/24유출이 6월 28일 02:28 UTC에 완전히 해소된 것으로 기록합니다 [1].

이 연속은 모든 사용자에게 단일한 연속 경험을 확립하지 않습니다. 경로는 플랩할 수 있습니다. 서로 다른 네트워크가 서로 다른 경로를 수용할 수 있습니다. 일부 트래픽은 폐기되고, 일부는 작동하는 Cloudflare 위치까지 긴 경로를 따라가고, 일부는 영향받지 않은 경로에 남을 수 있습니다. Cloudflare는 사용자 대면 결과를 1.1.1.1에 도달할 수 없거나 높은 지연으로 도달하는 것으로 설명했습니다. 그 예시 그래프는 독일과 미국을 다루었으며, 모든 출처 네트워크가 아니었습니다 [1].

이 연속은 의도도 확립하지 않습니다. Cloudflare는 무단/32출처에 대해 hijack이라는 용어를 사용하고/24유출 네트워크로 AS262504를 식별합니다. 이는 관측된 경로 상태에 대한 기술적으로 의미 있는 설명입니다. 이 기록의 공개 자료는 누군가 트래픽을 우회, 폐기 또는 방해할 의도가 있었는지 증명하지 않습니다. 책임성은 운영 발견을 동기에 관한 주장으로 바꾸지 않고도 제어에 배정될 수 있습니다.

호스트 경로가 어떻게 정상적인 애니캐스트 도달 가능성을 무력화할 수 있었는가

Cloudflare는 정상적으로 이를 덮는1.1.1.0/24를 애니캐스트 서비스의 일부로 여러 위치에서 광고합니다. 애니캐스트는 동일한 주소가 여러 사이트를 통해 도달 가능하도록 하며, BGP 정책과 토폴로지가 네트워크가 어느 사이트를 선택할지에 영향을 미칩니다. 이 구성은 규모와 근접성을 제공하지만, 여전히 라우팅 시스템이 승인된 경로를 선택하는 것에 의존합니다.

IP 전송은 최장 프리픽스 매칭을 사용합니다./32에 대한 경로는 하나의 IPv4 주소를 식별하며, 256개 주소를 덮는/24경로보다 더 구체적입니다. 두 항목이 전송 테이블에 도달하면/24가 더 매력적인 AS 경로를 가졌는지와 무관하게 1.1.1.1로 향하는 패킷에는/32가 승리합니다. 이 기계적 규칙은 호스트 경로가 블록의 모든 주소에 대한 이를 덮는 경로를 대체하지 않고도 하나의 주소에 대한 트래픽을 우회하거나 폐기할 수 있는 이유를 설명합니다.

디폴트프리 존은 정상적으로/24보다 긴 IPv4 경로를 필터링합니다. Cloudflare는 여러 공개 수집기와 경로 서버의 프리폴리시 BGP 모니터링 데이터에서/32를 관측했다고 보고했습니다. Cloudflare는 자체 임포트 정책이 이 경로를 RPKI 무효이자 디폴트프리 존에 무효한 것으로 거부했다고 밝혔습니다. 프리폴리시 관측은 이웃이 Cloudflare가 설치하지 않았음에도 업데이트를 보냈음을 보여주었기 때문에 여전히 가치가 있었습니다 [1].

수신과 수용 사이의 이 구분은 책임성 요건입니다. 경로 수집기는 경로가 발표되었다는 것을 기록할 수 있습니다. 라우터의 프리폴리시 텔레메트리는 이웃이 경로를 보냈다는 것을 보여줄 수 있습니다. 수용 경로 테이블은 임포트 정책이 경로를 허용했다는 것을 보여줄 수 있습니다. 전송 테이블은 경로가 트래픽에 사용 가능하게 되었다는 것을 보여줄 수 있습니다. 트래픽 측정은 결과를 보여줍니다. 각 기록은 경로의 서로 다른 단계에 답하며, 어느 것도 다른 모든 것을 대신해서는 안 됩니다.

Cloudflare의 ROA는 최대 길이/24로1.1.1.0/24에 대해 AS13335를 승인했습니다. 따라서 AS267613이 출처 발표한1.1.1.1/32경로는 출처 검증이 정의한 출처 조건과 최대 길이 조건 모두에 실패했습니다. 경로 출처 검증을 수행하는 네트워크는 그 경로를 무효로 분류하고 그 상태를 거부 정책에 연결할 수 있었습니다 [1][6][9].

핵심 단어는 "할 수 있었다"입니다. RFC 6811은 출처 검증을 정의하며, 보편적인 배치 의무가 아닙니다. RFC 8893은 용어와 운영 고려사항을 설명합니다. 네트워크는 RPKI 데이터를 수신하면서도 일관되게 적용하지 못할 수 있습니다. 경로를 분류하면서 거부하지 않을 수 있습니다. 예외를 만들 수 있습니다. 경로 서버와 그 클라이언트는 서로 다른 정책을 적용할 수 있습니다. 이 기록은 검증 근거가 존재했다는 것을 증명합니다; 모든 네트워크가 그것을 어떻게 사용했는지는 증명하지 않습니다 [9][10].

RTBH는 승인을 가용성으로 바꾸었다

Cloudflare가/32에 대해 제기한 가장 중대한 주장은 어느 티어원 트랜짓 제공자가 이를 원격 트리거 블랙홀 경로로 수용했다는 것입니다. RTBH는 합법적이고 널리 사용되는 방어입니다. 서비스 거부 공격 중 고객은 고객 연결이 포화되기 전에 목적지로 향하는 트래픽을 폐기하도록 제공자에게 요청할 수 있습니다. 하나의 목표에 대한 도달 가능성을 희생하는 것이 나머지 서비스를 보존할 수 있습니다.

RFC 7999는 경로가 폐기되어야 함을 신호하는 잘 알려진BLACKHOLE커뮤니티를 정의합니다. 이 커뮤니티의 효과는 설계상 파괴적이기 때문에 엄격한 범위와 필터링을 요구합니다. RFC 3882는 경로와 전송 동작이 조화되어 트래픽을 드랍하는 원격 트리거 블랙홀 기법을 설명합니다. 어느 문서도 어떤 이웃이든 어떤 주소에 대한 폐기를 요청할 자격이 있다는 의미가 아닙니다 [14][15].

이것이 이 사건이 노출한 책임성 경계입니다. 블랙홀 시스템은 구문보다 더 많은 것을 인증해야 합니다. 요청 당사자가 영향받은 프리픽스에 대해 승인되어야 하고, 요청된 프리픽스 길이가 허용되어야 하며, 이웃 관계가 요청을 허용해야 하고, 커뮤니티가 적절한 경계에서 제거되거나 제한되어야 하며, 그 동작이 관측 가능하고 취소 가능해야 합니다.

관련 없는 당사자로부터/32블랙홀 경로를 수용하는 제공자는, 일반 유니캐스트 경로 정책이 거부했을 작동적으로 유효하지 않은 출처를 작동적으로 유효하게 만들 수 있습니다. 방어 경로가 정상적인 승인을 우회하는 통로가 됩니다. Cloudflare의 설명은 바로 그것이 발생했다고 합니다: AS267613은 1.1.1.1을 블랙홀할 권한이 없었지만, 티어원 제공자는 지시를 수용하고 다운스트림 트래픽을 폐기했습니다 [1].

교훈은 RTBH를 포기하라는 것이 아닙니다. 그것 없이는 대량 공격에 직면한 운영자가 네트워크 용량을 보호할 선택지가 더 적어집니다. 교훈은 폐기 권한을 특권 기능으로 다루라는 것입니다. 명시적인 고객-프리픽스 결합, 검증된 최대 길이, 제한된 커뮤니티, 감사 가능한 활성화, 만료 또는 철회 처리, 그리고 요청된 폐기를 레지스트리 및 RPKI 근거와 비교하는 모니터링이 필요합니다.

이름이 공개되지 않은 제공자의 정확한 비공개 정책은 공개 기록에 없습니다. 제공자가 RFC 7999의 잘 알려진 커뮤니티를 사용했는지, 비공개 커뮤니티를 사용했는지, 다른 메커니즘을 사용했는지 추론하는 것은 틀립니다. Cloudflare는 그 결과를 RTBH로 보고했습니다. 방어 가능한 책임성 질문은, 검증되지 않은 어떤 구성 라인을 사용했는지가 아니라 제공자가 수신 경로를 폐기 동작으로 변환하기 전에 어떤 근거를 요구했는가입니다.

/24유출은 출처 시험은 통과했지만 경로 시험은 실패했다

유출된1.1.1.0/24는 경로 출처 승인의 상보적 한계를 보여줍니다. Cloudflare가 공개한 경로에서 AS13335는 가장 오른쪽 출처로 남았습니다. 검증자가 AS13335가/24를 출처 발표할 수 있는지만 묻는다면 답은 유효할 수 있습니다. 그러나 그것은 AS267613이 AS262504로 경로를 익스포트해야 했는지, AS262504가 AS1031로 익스포트해야 했는지, AS1031이 피어와 경로 서버에 배포해야 했는지에 답하지 않습니다 [1].

BGP의 AS 경로는 루프 방지 메커니즘이자 전파에 관한 근거입니다. 그러나 서명된 상업 계약은 아닙니다. 승인된 출처를 포함하는 경로가 여전히 예상되는 고객-제공자 또는 피어 관계를 위반할 수 있습니다. RFC 7908은 경로 유출을 의도된 범위를 넘어선 전파로 정의하고 일반적인 관계 실패에 대한 분류를 제공합니다 [8].

Cloudflare의 설명은 예시 경로를 분석하고 AS262504에서의 중대 전환을 식별합니다. Cloudflare는 AS267613을 기능적으로 Cloudflare의 피어로, AS262504를 AS267613의 고객으로 설명합니다. 그 설명에 따르면 AS262504는 제공자 측을 통해 Cloudflare 경로를 수신한 다음 상위인 AS1031로 발표했습니다. Cloudflare에 따르면 AS1031은 고객으로부터 경로를 수용하여 여러 피어링 위치에 걸쳐 재분배했습니다 [1].

이러한 관계 주장은 Cloudflare의 분석에서 나온 것이며 귀속된 상태로 유지되어야 합니다. 그럼에도 구체적인 제어를 드러냅니다. 제공자는 고객이 출처 발표하거나 발표하도록 승인된 프리픽스의 명시적 목록을 유지할 수 있습니다. RPKI 출처 상태, 인터넷 라우팅 레지스트리 데이터, 관측된 고객 콘 정보를 근거로 사용할 수 있습니다. 수용되는 경로 수를 제한하고, 예상치 못한 출처나 경로 패턴을 거부하며, 고객이 임의의 인터넷 경로에 대한 트랜짓이 되는 것을 막을 수 있습니다.

RFC 7454는 고객과 피어로부터 수신한 경로의 필터링을 포함한 BGP 운영 관행을 설명합니다. RFC 8212는 준수 동작에서 eBGP 경로에 대한 명시적 임포트 및 익스포트 정책을 요구함으로써 위험한 역사적 기본값을 바꿉니다. 이러한 조치는 우연한 개방성을 줄이지만, 명시적 고객 정책이 지나치게 넓다는 것을 자동으로 감지하지는 않습니다. 인접 AS만 검사하는 필터는 여전히 고객이 전파하도록 승인되지 않은 경로를 수용할 수 있습니다 [11][12].

이것이 Cloudflare의 설명에서 AS1031이 중요한 이유입니다. 원래 유출은 고객에서 시작될 수 있지만, 반경은 누가 수용하고 재분배하는가에 달려 있습니다. 트랜짓 또는 익스체인지 운영자는 모든 고객 내부의 모든 오류에 책임이 있지 않습니다. 자신의 경계 내 수용 및 익스포트 제어, 그 제어가 사용하는 근거, 그리고 통지를 받은 후 나쁜 경로를 철회하거나 격리할 수 있는 능력에 책임이 있습니다.

Roles와 OTC는 관계 근거를 추가한다

RFC 9234는 BGP Roles와 Only-to-Customer 속성으로 경로 유출을 다룹니다. Roles는 두 eBGP 스피커가 제공자, 고객, 피어, 경로 서버 같은 관계를 설명하도록 합니다. OTC는 경로에 표시를 하여 수신 네트워크가 그 역할과 일치하지 않는 전파를 감지할 수 있게 합니다 [13].

이 제어는 RPKI 출처 검증이 다루지 않는 질문을 목표로 합니다: 승인된 출처가 발표한 후 경로가 어디까지 이동할 수 있는가. 단순화하면, 제공자나 피어로부터 학습한 경로는 그 네트워크가 승인된 트랜짓인 것처럼 다른 제공자나 피어에게 제공되어서는 안 됩니다. 관계 메타데이터는 그 규칙을 인접 경계에서 기계 검증 가능하게 만들 수 있습니다.

OTC는 2024년 6월에 무슨 일이 있었는지에 대한 소급적 증명이 아닙니다. 여기 사용된 공개 기록은 AS267613, AS262504, AS1031, 그들의 경로 서버 또는 영향받은 다운스트림 네트워크가 Roles를 협상하거나 OTC를 강제했는지 확립하지 않습니다. 이 표준은 실패 클래스와 일치하는 강제 가능한 경계를 식별하기 때문에 제어 참조로 유용합니다. 이 사건에서 실패한 것으로 알려진 제어로 설명되어서는 안 됩니다.

Role 메타데이터는 기본적인 고객 필터링도 대체할 수 없습니다. 네트워크는 여전히 어느 프리픽스, 출처, 경로 볼륨이 고객에게 타당한지 알아야 합니다. 조용히 영구적인 우회로 변하지 않는 예외 처리가 필요합니다. 급격한 변화에 대한 모니터링과 경로를 철회할 수 있는 운영자에게 닿는 연락 경로가 필요합니다.

가장 강한 설계는 여러 독립적 검사를 사용합니다. 출처 검증은 출처가 승인되었는지 묻습니다. 프리픽스 필터링은 이 고객이 자원을 발표할 수 있는지 묻습니다. Role과 OTC 검사는 경로가 허용된 관계를 통해 이동했는지 묻습니다. 최대 프리픽스 제어는 볼륨의 급격한 변화를 감지합니다. 경로 이상 시스템은 업데이트를 예상 토폴로지와 비교합니다. 어느 것도 완벽하지 않지만, 함께 있으면 하나의 실수 또는 악의적인 발표가 널리 사용 가능하게 될 가능성을 줄입니다.

할당 및 ROA 기록은 근거이지 원격 제어가 아니다

1.1.1.0/24의 역사는 기록 보관 계층을 특히 가시적으로 만듭니다. APNIC의 prop-109는1.0.0.0/24와1.1.1.0/24를 연구 프리픽스로 APNIC Labs에 할당했습니다. 정책 자료는 예제와 비공개 구성에서 오랫동안 사용되어 왔기 때문에 상당한 비청구 트래픽을 끌었던 주소 블록을 설명합니다. APNIC는 이후 Cloudflare가 1.1.1.1 리졸버 서비스를 운영하는 합의에 들어갔습니다 [2][4][5].

할당 기록은 레지스트리 시스템 아래 누가 번호 자원을 보유하고 관리하는지에 답합니다. Cloudflare의 ROA는 어느 출처 AS가 프리픽스에 대해 승인되었고 어떤 최대 프리픽스 길이가 포함되는지에 답합니다. 이들은 내구성 있는 근거 객체입니다. 자동화, 분쟁 해결, 사후 인시던트 재구성을 지지합니다. 그러나 그것 자체로는 패킷을 Cloudflare로 흐르게 하지 않습니다.

이 구분이 중요한 이유는 "소유"라는 단어가 운영을 가릴 수 있기 때문입니다. 주소 블록은 선언만으로 보호되지 않습니다. 인터넷의 라우터들은 이웃으로부터 업데이트를 수신하고 로컬 정책을 적용합니다. 레지스트리는 관련 없는 라우터가 경로를 발표하는 것을 직접 막을 수 없습니다. 의존 네트워크는 기록을 검색하고 검증하고, 무효 또는 미지가 자신의 리스크 모델에서 무엇을 의미하는지 결정하고, 그 결정을 실행 중인 구성에서 강제해야 합니다.

복구 중에도 마찬가지입니다. 나쁜 경로를 철회하지 않고 레지스트리 객체를 갱신하면 전송 테이블에서 경로가 사라지지 않습니다. 수집기 및 구성 근거를 보존하지 않고 경로를 철회하면 서비스는 복구되지만 조사는 약화됩니다. 효과적인 책임성은 기록과 실행 상태를 연결합니다: 프리픽스, 승인된 출처, 관측된 경로, 이웃, 정책 결정, 선택된 경로, 전송 결과, 철회 시각.

이것이 레지스트리를 원장으로 보는 모델의 실용적 가치입니다. 레지스트리 무결성을 훼손하지 않습니다. 레지스트리 데이터에 정확한 역할을 부여합니다: 고유하고 정확한 자원 기록, 이전 이력, 보안 메타데이터, 검증의 근거. 또한 레지스트리가 실행할 수 없는 모든 로컬 정책 결정에 대한 비난을 방지하면서, 사용할 수 있었던 기록을 무시한 네트워크에 책임을 묻게 합니다.

수집기는 전파를 보여주지, 모든 전송 결정을 보여주지 않는다

Cloudflare는 공개 경로 수집기를 사용하여/32와/24의 목격을 보여주었습니다. RouteViews와 RIPE RIS는 참여 네트워크로부터 BGP 피드를 받아 업데이트와 테이블 스냅샷을 보존합니다. 그 데이터는 경로가 수집기에서 언제 가시적이었는지, 어느 피어가 보냈는지, 어떤 AS 경로와 속성이 기록되었는지, 철회 또는 대체가 언제 나타났는지 확립하는 데 도움이 됩니다 [1][16][17].

그 근거는 불가결하지만 한계가 있습니다. 수집기는 그 피어들이 익스포트하는 뷰만 봅니다. 모든 네트워크의 모든 경로를 보지 못합니다. BGP 업데이트는 수신 라우터가 그 경로를 베스트로 설치했다는 것을 증명하지 않습니다. 선택된 제어 평면 경로는 모든 패킷이 그것을 따랐다는 것을 증명하지 않습니다. 누락된 업데이트는 경로가 필터링되었거나, 수집기에 익스포트되지 않았거나, 수집기의 가시 범위 밖이라는 의미일 수 있습니다.

이러한 한계는 수집기를 약한 근거로 만들지 않습니다. 주장을 정확하게 만듭니다. 수집기 데이터는 발표가 비공개 경계를 벗어나 외부 관측자에게 도달했다는 것을 뒷받침할 수 있습니다. 전파 경로와 시각을 보여줄 수 있습니다. 보호된 프리픽스에 예상치 못한 출처나 경로가 나타날 때 경보를 지지할 수 있습니다. 철회가 완화 이후 가시적으로 나타나는지 검증할 수 있습니다.

서비스 운영자는 외부 관측을 내부 텔레메트리와 결합해야 합니다. 프리폴리시 모니터링은 이웃이 무엇을 보냈는지 보여줍니다. 포스트폴리시 경로 테이블은 무엇이 수용되었는지 보여줍니다. RIB와 FIB 상태는 제어 평면 선택과 전송 설치를 보여줍니다. 흐름, 지연, 손실 데이터는 결과를 보여줍니다. 피어링 및 티켓 기록은 대응을 보여줍니다. 타임스탬프와 식별자가 이러한 계층을 상관시킬 수 있을 때 근거 연쇄가 강해집니다.

수집기는 독립적 검증도 가능하게 합니다. Cloudflare의 포스트는 자사의 대응과 관측된 비공개 효과의 주된 출처입니다. RouteViews와 RIPE RIS는 별개의 공개 인프라입니다. 운영자 텔레메트리와 수집기 관측 사이의 일치는 연대기를 강화할 수 있지만, 공개 데이터는 비공개 의도, 모든 고객 효과, 전체 내부 결정 과정을 드러낼 수 없습니다.

영향은 실재했지만 균일하지 않았고 전 세계적으로 측정되지 않았다

Cloudflare는 영향받은 사용자가 1.1.1.1에 도달할 수 없거나 높은 지연으로만 도달할 수 있었다고 밝혔습니다. 블랙홀 경로는 하나의 실패 모드를 설명합니다: 트래픽이 Cloudflare에 도달하기 전에 폐기되었습니다. 유출된/24는 다른 것을 설명합니다: 트래픽이 브라질로 이동하여 정상적인 애니캐스트 선택보다 훨씬 긴 경로를 통해 결국 Cloudflare 위치에 도달할 수 있었습니다 [1].

Cloudflare의 독일과 미국 예시 그래프는 사건의 일부 기간 동안 트래픽이 브라질 데이터센터에 착지하는 것을 보여줍니다. Cloudflare는 그려진 트래픽이 각 출처 국가의 전체 요청 중 상대적으로 작은 비중을 나타낼 수 있다고 주의했습니다. 그 주의는 그래프와 함께 다니는 것이 좋습니다. 어느 국가든 대부분의 사용자가 영향받았다고 추론하는 것은 오해의 소지가 있습니다 [1].

APNIC의 논평은 이 사건이 전 세계적으로 가시적이지 않았으며 전체 인터넷 사용자 기반 대비 미미했을 가능성이 높다고 밝히면서도, 많은 절대 사용자 수에 영향을 미쳤을 수 있음을 인정했습니다. Internet Society Pulse는 여러 네트워크와 국가에 걸친 관측을 설명했습니다. 서로 다른 가시성 시스템, 정의, 관측 지점은 서로 다른 범위 설명을 낳을 수 있습니다 [2][3].

책임 있는 서술은 이러한 진술을 분리해 둡니다. 평균을 내지 않고, 가장 큰 수치를 확정적 영향으로 선택하지 않고, 네트워크 관측을 사용자 수로 변환하지 않습니다. 이용 가능한 공개 기록은 완전한 분모, 영향받은 접속 네트워크의 전체 목록, 쿼리 실패 총계, 독립적으로 검증된 금전 손실을 제공하지 않습니다.

전 세계 측정의 부재는 책임성의 부재가 아닙니다. 제어는 소수의 사용자만 마주할 때도 중요할 수 있습니다. 1.1.1.1은 이를 구성하는 사람들에게 중대한 의존성입니다. 티어원 블랙홀은 그 제공자에 의존하는 모든 다운스트림 경로에 영향을 미칠 수 있습니다. 경로 서버 유출은 출처 네트워크를 넘어 확산될 수 있습니다. 적절한 기준은 비례하는 근거입니다: 측정할 수 있는 것을 측정하고, 남아있는 미지를 진술하며, 불확실성이 명확히 중요했던 제어를 지우게 두지 않는 것입니다.

Cloudflare의 격리는 단독 조치의 한계를 보여주었다

Cloudflare의 즉각적인 제어는 선언적이기보다 운영적이었습니다. 인시던트를 발생시키고, 잘못된 경로로 트래픽을 끌던 피어링 지점을 비활성화하고, 명시된 네트워크에 연락하고,/24유출이 해소될 때까지 경로 상태를 모니터링했습니다. 이러한 조치는 Cloudflare의 경계 내 노출을 줄이고 운영 조율을 통해 압력을 적용할 수 있었습니다 [1].

그러나 다른 네트워크의 라우터를 직접 편집할 수는 없었습니다. 피어링 위치를 비활성화하는 것은 Cloudflare가 트래픽을 교환하는 위치를 바꾸지만, 다른 곳에서 출처 발표되거나 전파된 경로를 자동으로 철회하지 않습니다. Cloudflare에 따르면 상파울루로 향하는 오래된 경로는 이전 격리 이후에도 여전히 가시적이었습니다. 완전한 해소에는 발표를 담당하는 네트워크의 조치가 필요했습니다 [1].

이러한 제어 분할이 인시던트 대응에 신뢰할 수 있는 연락처와 근거 패키지가 필요한 이유입니다. 유용한 통지는 프리픽스, 관측된 출처와 경로, 수집기와 타임스탬프, 예상되는 승인, 효과, 요청된 조치를 식별합니다. 일반 우편함에 사라지지 않고 네트워크 운영 팀에 닿아야 합니다. 수신자는 관련 없는 기밀 구성을 노출하지 않으면서 철회를 확인하고 정책 수정을 설명할 수 있어야 합니다.

Cloudflare는 또한 다양한 관측 지점에서 고가시성 서비스를 모니터링할 책임이 있었습니다. 공개 타임라인은 첫 공개 발표와 20:03의 내부 인시던트 사이에 한 시간 이상을 보여줍니다. 그 간격만으로 모니터링 실패를 증명하지 않습니다: 공개 기록은 영향이 경보 임계를 넘은 시각, 어느 신호가 이용 가능했는지, 이전 사건이 Cloudflare의 시스템에 가시적이었는지 말하지 않습니다. 그것은 검토를 위한 질문을 정의합니다: 어떤 관측이 예상치 못한 출처나 경로를 감지했어야 하고, 얼마나 빨리 확대되었어야 하는가?

따라서 강한 사후 인시던트 기록에는 첫 외부 관측까지의 시간, 내부 탐지까지의 시간, 인시던트 선언까지의 시간, 첫 격리까지의 시간, 담당 네트워크 접촉까지의 시간, 호스트 경로 철회까지의 시간, 유출 철회까지의 시간, 검증된 서비스 복구까지의 시간이 포함되어야 합니다. 이러한 척도는 서로 다른 소유자에 해당합니다. 이들을 하나의 "해소 시간"으로 결합하면 지연이 어디에 쌓였는지 가려집니다.

예방은 각 경계에서 평가되어야 한다

/32의 출처 경계는 승인되지 않은 주소의 호스트 경로를 AS가 발표하는 것을 막아야 합니다. 후보 구성 검증은 활성화 전에 의도된 프리픽스를 레지스트리, IRR, RPKI 데이터와 비교할 수 있습니다. 익스포트 정책은 이웃과 서비스별로 발표 프리픽스를 제한할 수 있습니다. 최대 프리픽스 길이는/24만 승인된 경우/32를 차단할 수 있습니다. 변경 후 모니터링은 실제 Adj-RIB-Out을 승인된 집합과 비교할 수 있습니다.

수신 경계는 타당하지 않거나 무단인 경로를 거부해야 합니다. RPKI 출처 검증은/32에 명확한 무효 상태를 제공했습니다. 디폴트프리 존 프리픽스 길이 필터는 또 다른 신호를 제공했습니다. 고객 프리픽스 승인은 관계 검사를 제공했습니다. 경로를 수용한 네트워크는 어느 규칙이 그것을 허용했는지, 예외가 정상 거부를 우회했는지 보여줄 수 있어야 합니다.

RTBH 경계는 자체 승인 테이블이 필요합니다. 제공자는 고객이 해당 고객과 연관된 프리픽스만, 합의된 최대 길이 이내, 지정된 세션과 커뮤니티를 통해 블랙홀하도록 허용할 수 있습니다. 활성화는 요청 이웃, 경로, 검증 상태, 범위, 타임스탬프, 만료와 함께 기록되어야 합니다. 무효한 출처나 무관한 프리픽스는 폐기 경로가 되지 않고 실패 시 닫혀야 합니다.

/24전파 경계에는 고객 및 역할 제어가 필요합니다. Cloudflare의 관계 분석이 올바르다면 AS262504의 익스포트 정책은 제공자로부터 학습한 경로가 다른 제공자로 전송되는 것을 막았어야 합니다. AS1031의 고객 정책은 고객의 승인된 집합을 벗어나거나 관계와 일치하지 않는 경로를 거부했어야 합니다. 경로 서버는 자신의 운영 모델에 적합한 제어를 적용하거나 활성화해야 하고, 참여자는 경로 서버가 모든 클라이언트 경로를 안전하게 만든다고 가정해서는 안 됩니다.

서비스 경계에는 다양한 도달 가능성 탐침과 경로 보안 경보가 필요합니다. 리졸버 운영자는 여러 지역에서 쿼리 성공, 지연, 경로 출처, 더 구체적인 발표, 예상치 못한 AS 경로를 모니터링할 수 있습니다. 알려진 서비스 주소에 영향을 미치는 라우팅 이상이 애플리케이션 전용 문제로 취급되지 않도록 그러한 신호를 상관시킬 수 있습니다.

마지막으로 근거 경계에는 보존이 필요합니다. 구성 버전, 검증 결과, BGP 업데이트, RIB 결정, FIB 상태, 블랙홀 활성화, 수집기 관측, 피어링 변경, 인시던트 통신은 안정적인 타임스탬프를 공유해야 합니다. 그 연쇄 없이는 운영자가 서비스를 복구하더라도 어느 제어가 실패했는지 설명하거나 수정이 그 실패 클래스를 해결한다는 것을 증명할 수 없습니다.

탐지는 나쁜 출처, 나쁜 경로, 나쁜 동작을 구분해야 한다

이 사건에 대해 단일한 "경로 이상" 경보는 충분하지 않습니다./32는 예상치 못한 출처 경보, RPKI 무효 경보, 과도한 프리픽스 길이 경보를 발생시킬 수 있었습니다./24는 AS13335가 출처로 남았고 프리픽스 길이가 유효했기 때문에 처음 두 경보를 발생시키지 않았을 수 있습니다. 경로-관계 또는 고객-승인 분석이 필요했습니다.

블랙홀 동작은 또 다른 계층을 추가합니다. RTBH 시스템은 프리픽스에 대해 승인되지 않은 이웃이 폐기 경로를 요청할 때, 경로가 RPKI 무효일 때, 길이가 고객의 허용을 초과할 때, 폐기가 고가치 공유 서비스에 영향을 미칠 때 경보를 발해야 합니다. 경로는 일반 전송에 대해 무효일 수 있으면서도, 동등한 승인 검사가 없는 특화된 완화 경로에 의해 수용될 수 있습니다.

이러한 경보는 그 근거를 보존해야 합니다. "RPKI 무효"는 검증된 프리픽스, 출처, 최대 길이, 검증자 상태를 기록해야 합니다. "고객 무단"은 승인된 프리픽스 집합과 그 출처를 식별해야 합니다. "역할 위반"은 예상되는 관계와 관측된 익스포트를 식별해야 합니다. "예상치 못한 블랙홀"은 신호 커뮤니티 또는 메커니즘과 적용된 범위를 식별해야 합니다.

경보 품질이 중요한 이유는 위양성이 나중에 영구적인 우회로 되는 예외를 낳을 수 있기 때문입니다. 운영자는 경계가 있고 설명 가능한 근거와 승인을 안전하게 갱신하는 방법이 필요합니다. 이것이 어느 단일 데이터베이스도 의심 없는 주권으로 다뤄서는 안 되는 또 다른 이유입니다. 레지스트리, RPKI, 고객 계약, 운영 토폴로지, 관측된 라우팅 상태는 조화되어야 하는 별개의 기록입니다.

격리와 복구에는 독립적 증명이 필요하다

호스트 경로의 격리는 출처를 중단하고, 블랙홀 및 전송 정책에서 제거하고, 외부 관측 지점에서 철회를 확인하는 것을 의미합니다./24유출의 격리는 AS262504에서 무단 익스포트를 중단하고 AS1031과 다른 네트워크에서 이후 전파를 중단하는 것을 의미합니다. Cloudflare의 피어링 변경은 자신의 제어 아래 트래픽 경로를 줄였지만 그 철회의 대체물이 아니었습니다.

복구는 세 계층에서 입증되어야 합니다. 경로 상태는 승인된 출처와 경로로 돌아가야 합니다. 전송은 트래픽을 폐기하거나 우회시키지 않고 의도된 Cloudflare 애니캐스트 위치로 보내야 합니다. 리졸버 서비스 측정은 정상적인 성공과 지연을 보여주어야 합니다. 경로 검증 없는 초록색 애플리케이션 대시보드는 남아있는 이상 경로를 놓칠 수 있습니다; 사용자 측정 없는 깨끗한 경로 테이블은 서비스 문제를 놓칠 수 있습니다.

수정에는 내구성도 필요합니다. 출처 네트워크는/32가 다시 출처 발표되지 못하게 무엇이 막았는지 설명해야 합니다. 유출 네트워크는 익스포트를 관계 정책에 결합해야 합니다. 증폭 네트워크는 고객 수용과 재분배를 수정해야 합니다. RTBH 제공자는 무관한 이웃이 프리픽스에 대한 폐기를 승인할 수 없도록 해야 합니다. Cloudflare는 자사 모니터링이 같은 시그니처를 더 빨리 감지하는지 시험해야 합니다.

공개 근거는 그 중 어느 변경이 배치되었는지 확립하지 않습니다. Cloudflare는 예방 메커니즘에 관해 네트워크들과 협의했다고 하며, RPKI, RTBH 승인, OTC, ASPA를 관련 방향으로 논의합니다 [1]. 이 제안은 유용하지만, 제안되거나 논의된 제어는 검증된 수정이 아닙니다. 책임성은 실패 조건에 결부된 시험 결과를 요구합니다.

경계를 지킨 책임성 매트릭스

/32의 출처 AS는 호스트 경로가 만들어지고 익스포트되었는지를 제어했습니다. 그 근거에는 승인된 프리픽스 목록, 구성 변경 기록, Adj-RIB-Out, 철회 확인이 포함되어야 합니다. 공개 기록은 관측된 발표를 식별하지만 내부 원인이나 의도는 공개하지 않습니다.

AS262504는 하나의 관계를 통해 학습한/24가 상위로 익스포트되었는지를 제어했습니다. 관련 근거는 이웃 역할, 임포트 출처, 익스포트 정책, 경로 승인, 사후 인시던트 수정입니다. Cloudflare는 이를 유출 네트워크로 부르지만, 더 완전한 내부 설명은 여기 사용된 공개 기록에 없습니다 [1].

AS1031은 자신의 경계에서 고객 경로 수용과 재분배를 제어했습니다. 관련 근거는 승인된 고객 프리픽스 집합, 필터링 정책, 경로 서버 또는 익스체인지 설계, 최대 프리픽스 처리, RPKI 및 관계 검사, 철회 대응입니다. Cloudflare는 광범위한 증폭을 AS1031에 귀속시키며, 이 기사는 그 공개 분석을 넘어 비공개 구성을 추론하지 않습니다 [1].

티어원 제공자는 수신 경로가 RTBH를 발동할 수 있는지와 폐기가 얼마나 넓게 적용되었는지를 제어했습니다. 핵심 근거는 고객 승인, 경로 및 프리픽스 길이 검증, 커뮤니티 범위, 활성화 로그, 철회입니다. 여기 사용된 출처에서 Cloudflare는 제공자를 지명하지 않으므로 분석이 그 신원에 대해 추측해서는 안 됩니다 [1].

Cloudflare는 자신의 ROA, 임포트 정책, 서비스 모니터링, 피어링 대응, 고객 통신, 공개 공시를 제어했습니다. 자사 임포트에서/32를 거부했고 격리 중 영향받은 피어링을 비활성화했다고 밝혔습니다. 검토 질문은 경로 및 서비스 모니터링이 탐지를 단축할 수 있었는지, 외부 조율과 복구 근거가 충분했는지입니다 [1][6].

APNIC과 RPKI 시스템은 자신의 정의된 역할 내에서 기록 무결성을 제어했습니다. 할당 및 승인 기록은 거부를 지지할 수 있는 근거를 제공했습니다. 그러나 모든 의존 라우터를 제어하지는 않았습니다. 그들의 책임성은 기록의 정확성, 가용성, 보안 게시이며, 다른 운영자의 수용 정책에 대한 직접 책임이 아닙니다 [4][5][6].

RouteViews와 RIPE RIS는 수집기 운영과 근거 게시를 제어했습니다. 외부 전파를 검사 가능하게 만드는 데 도움이 되었습니다. 경로를 승인하거나, 고객 전송을 위해 선택하거나, 철회하지는 않았습니다. 그들의 가치는 라우팅 시스템의 어느 부분이 노출되었는지에 대한 독립적 현실 검증입니다 [16][17].

표준이 증명할 수 있는 것과 없는 것

RFC 4271은 자율 시스템이 도달 가능성을 교환하는 BGP 메커니즘을 설명합니다. 이 사건에 대한 책임은 부여하지 않습니다. RFC 7908은 경로 유출 범주를 제공하지만, 분류는 비공개이거나 논쟁적일 수 있는 관계 사실에 달려 있습니다. RFC 6811과 RFC 8893은 출처 검증을 설명하며, 실제 거부는 여전히 로컬 정책입니다 [7]-[10].

RFC 7454와 RFC 8212는 명시적 필터와 정책에 대한 강한 이유를 확립합니다. 특정 운영자가 정책이 없었다는 것을 증명하지 않고, 명시적 정책이 충분히 좁다는 것을 보장하지 않습니다. RFC 9234는 Roles와 OTC를 제공하지만, 출처 기록은 인시던트 참여자에 의한 배치를 확립하지 않습니다 [11]-[13].

RFC 7999와 RFC 3882는 블랙홀링이 심각한 범위 및 승인 요건을 가진 의도적인 네트워크 제어 메커니즘임을 보여줍니다. 지명되지 않은 티어원 제공자가 사용한 정확한 신호 구현을 식별하지 않습니다. 사건별 주장은/32가 RTBH로 수용되었다는 Cloudflare의 귀속된 보고로 남습니다 [1][14][15].

따라서 표준은 제어 지도로 사용하는 것이 가장 좋습니다. 운영자가 명시적 정책, 검증된 출처, 경계가 있는 고객 발표, 부호화된 관계, 제한된 블랙홀 권한, 보존된 근거를 갖고 있었는지 묻는 데 도움이 됩니다. 공개 기록에 없는 사후 인시던트 감사를 발명하는 데 사용되어서는 안 됩니다.

경로 전파 책임성 시험

2024년 6월의 사건은 인터넷 책임성이 자원 소유에서 멈출 수 없는 이유를 보여줍니다. APNIC의 기록과 Cloudflare의 ROA는 강한 근거를 제공했습니다. Cloudflare의 자체 임포트 정책은 그 근거를 사용해/32를 거부한 것으로 알려졌습니다. 그럼에도 다른 네트워크는 1.1.1.1에 대한 도달 가능성을 제어해서는 안 되었던 경로를 수용, 전파 또는 이에 작동했습니다 [1][4][5][6].

책임성은 첫 나쁜 발표에서 멈출 수도 없습니다./24유출은 이후 네트워크들이 수용하고 재분배했기 때문에 반경을 얻었습니다. 티어원 블랙홀은 방어 메커니즘이 무단 경로를 폐기 요청으로 취급했기 때문에 효과를 얻었습니다. 각 경계는 정보를 작동 상태로 변환했습니다.

실용적인 시험은 다섯 가지 질문을 따릅니다.

첫째, 예방: 운영자가 활성화 전에 이웃이 이 프리픽스를 이 길이로 출처 발표, 전파 또는 블랙홀하도록 승인되었다는 것을 증명할 수 있었는가?

둘째, 거부: 실행 중인 정책이 출처, 프리픽스, 고객, 관계 근거를 사용해 무효하거나 범위 밖의 경로를 거부했는가?

셋째, 관측: 내부 텔레메트리와 독립 수집기가 경로가 수신, 수용, 익스포트, 선택, 철회된 시각을 보여줄 수 있었는가?

넷째, 격리: 운영자가 다른 모든 네트워크를 기다리지 않고 자신의 전파나 폐기 동작을 중단할 수 있었고, 남아있는 나쁜 상태를 제어하는 당사자들에게 도달할 수 있었는가?

다섯째, 복구: 경로 상태, 전송, 리졸버 성능이 정상으로 돌아왔고, 반복 가능한 시험이 같은 승인 실패가 더 이상 통과할 수 없다는 것을 보여주었는가?

이 질문들은 의도에 관한 주장을 요구하지 않습니다. 실용적 제어에 책임을 부여합니다. 출처 네트워크는 자신의 익스포트에 답합니다. 고객과 제공자는 관계 정책에 답합니다. 블랙홀 운영자는 폐기 승인에 답합니다. 서비스 운영자는 모니터링과 격리에 답합니다. 레지스트리와 RPKI 게시자는 신뢰할 수 있는 근거에 답합니다. 수집기는 관측의 무결성과 한계에 답합니다.

그 결과는 현실 계층 표준입니다. 권위적인 상태는 가장 좁은 공개 약속이나 가장 자신감 있는 소유 주장이 아닙니다. 실행 중인 라우터가 수용한 경로, 그것이 설치한 전송 동작, 사용자가 마주한 트래픽 결과, 그리고 그 사실을 검사 가능하게 만든 근거입니다.

Cloudflare의 1.1.1.1 사건은 어느 하나의 제어가 쓸모없다는 것을 보여주지 않았습니다. 여러 제어가 상호 잠겨야 하는 이유를 보여주었습니다. 출처 검증은/32를 거부할 수 있었지만 유효한 출처를 가진 유출 경로는 거부하지 못했습니다. 관계 정책은/24를 제약할 수 있었지만 자체로 RTBH를 승인하지는 못했습니다. 할당 기록은 자원 맥락을 확립했지만 필터를 강제할 수 없었습니다. 수집기는 전파를 드러냈지만 철회할 수 없었습니다.

따라서 지속되는 책임성 요건은 정확합니다: 발표를 도달 가능성이나 폐기로 바꿀 수 있는 모든 네트워크는, 경로가 왜 승인되었는지, 어떤 근거를 사용했는지, 모순을 얼마나 빨리 감지했는지, 수정을 어떻게 증명했는지 보여줄 수 있어야 합니다. 그보다 못하면 익숙한 주소가 서류에는 존재하지만 패킷이 실제로 지나는 경로에는 존재하지 않는 제어에 의존하게 됩니다.

출처

  1. https://blog.cloudflare.com/cloudflare-1111-incident-on-june-27-2024/
  2. https://blog.apnic.net/2024/08/02/when-routing-breaks-your-open-dns-service/
  3. https://pulse.internetsociety.org/en/news/2024/07/cloudflare-dns-outage-traced-to-bgp-hijacking-incident/
  4. https://www.apnic.net/community/policy/proposals/prop-109/
  5. https://www.apnic.net/wp-content/uploads/prop-109/assets/prop-109-v001.txt
  6. https://rpki.cloudflare.com/?prefix=1.1.1.0%2F24&view=explorer
  7. https://www.rfc-editor.org/rfc/rfc4271
  8. https://www.rfc-editor.org/rfc/rfc7908
  9. https://www.rfc-editor.org/rfc/rfc6811
  10. https://www.rfc-editor.org/rfc/rfc8893
  11. https://www.rfc-editor.org/rfc/rfc7454
  12. https://www.rfc-editor.org/rfc/rfc8212
  13. https://www.rfc-editor.org/rfc/rfc9234
  14. https://www.rfc-editor.org/rfc/rfc7999
  15. https://www.rfc-editor.org/rfc/rfc3882
  16. https://www.routeviews.org/routeviews/
  17. https://ris.ripe.net/docs/