요약

  • RFC 8955는 BGP가 트래픽 매칭 규칙과 조치를 전달하도록 하지만, 기본 검증 절차는 권한을 가장 잘 일치하는 유니캐스트 경로의 발기자에게 연결하고, 해당 경로가 바뀔 때 규칙을 다시 검토하도록 요구합니다.
  • Susan Hares는 RFC 8955의 공동 저자이며 IPv6 보완 표준인 RFC 8956의 편집자입니다. 다른 저자 그룹이 쓴 RFC 9117은 이후 중앙 컨트롤러 및 라우트 서버 설계를 위해 하나의 로컬 도메인 내부에서 검증을 완화했지만, 도메인 전반에 걸쳐 필터링할 일반적인 권리를 만든 것은 아닙니다.

패킷의 처리 방식을 바꿀 수 있는 경로

BGP는 보통 도달 가능성을 교환하는 시스템으로 설명됩니다. FlowSpec은 그보다 운영적으로 강력한 어휘를 추가합니다. FlowSpec의 NLRI(Network Layer Reachability Information)는 목적지 또는 발신지 프리픽스, 프로토콜, 포트, ICMP 필드, TCP 플래그, 패킷 길이, DSCP 또는 조각 속성을 매칭할 수 있습니다. 확장 커뮤니티는 그다음 조치를 부착할 수 있습니다: 바이트 또는 패킷 속도 부과, 단말 동작이나 샘플링 동작 설정, 라우트 타겟을 이용한 트래픽 리디렉션, 또는 패킷 마킹입니다. 속도 0은 폐기를 의미합니다.

정당한 용도는 즉각적입니다. 서비스 거부 공격이 진행되는 동안 운영자는 기술자가 모든 장비를 하나씩 설정하는 것보다 빠르게 하나의 정밀한 규칙을 많은 라우터에 배포해야 할 수 있습니다. VPN 필터링과 중앙 관리 네트워크 기능도 비슷한 수요를 만듭니다. 그러나 같은 기능은 단순히 또 하나의 경로가 아닙니다. 잘못되거나 승인되지 않은 도달 가능성 광고는 트래픽을 엉뚱한 방향으로 보낼 수 있지만, 잘못된 FlowSpec 광고는 매칭되는 트래픽의 처리 방식을 직접 바꿀 수 있습니다.

IETF Datatracker의 Susan Hares 공식 프로필은 그녀의 오랜 표준 참여 기록을 담고 있습니다. 이 좁은 이야기에서 관련 문서 사슬은 정확합니다. 2020년 12월에 Standards Track으로 발표된RFC 8955는 Christoph Loibl, Susan Hares, Robert Raszuk, Danny McPherson, Martin Bacher를 저자로 기록하고 있습니다. 이 문서는 최초의 IPv4 FlowSpec 규격을 개정하며 RFC 5575와 RFC 7674를 대체합니다. IPv6 확장인RFC 8956은 Loibl, Raszuk, Hares를 편집자로 명시합니다.

이는 집단적 IETF 결과 안에서의 기여이며, Hares가 혼자 FlowSpec을 발명했거나 그 배포를 통제한다는 주장이 아닙니다. 이 구분은 중요합니다. 표준 자체가 권한을 분산하기 때문입니다. 한 스피커가 규칙을 발기하고, 다른 네트워크가 이를 검증하며, 로컬 정책이 그것이 포워딩 하드웨어에 도달할지와 어떻게 도달할지를 결정합니다.

결정적 순서만으로는 충분한 권한이 아니다

RFC 8955는 구현들이 일관된 결과에 도달할 수 있도록 겹치는 FlowSpec 규칙의 순서를 정의합니다. 또한 조치가 부착되지 않은 매치는 기본적으로 수용된다고 명시합니다. 이러한 세부 사항들은 규칙 언어를 예측 가능하게 만듭니다. 그러나 더 중대한 질문에는 답하지 않습니다. 왜 이 특정 BGP 이웃이 이 특정 처리 요청을 할 수 있어야 하는가?

기본 검증 절차는 보통의 유니캐스트 라우팅에서 권한을 빌려 이 물음에 답합니다. 목적지 프리픽스를 포함한 FlowSpec 규칙은 가장 잘 일치하는 유니캐스트 경로와 대조됩니다. 규칙의 발기자는 그 경로의 발기자와 일치해야 하고, 다른 이웃 자율 시스템이 보낸 더 구체적인 경로는 그 요청을 무효화할 수 있습니다. 외부 BGP 스피커의 경우 FlowSpec 경로의 맨 왼쪽 자율 시스템도 유니캐스트 경로의 맨 왼쪽 AS와 대조됩니다.

이것은 선의를 입증하는 암호학적 증거가 아닙니다. 범위 검사입니다. 이웃 AS는 이미 관련 목적지로 가는 직접 경로 위에 있으며 트래픽을 받은 뒤 폐기할 수도 있습니다. 이웃이 상류에 같은 트래픽을 더 일찍 폐기하거나 속도 제한해 달라고 요청할 수 있도록 허용하면 용량을 절약할 수 있지만, 그 요청의 정당성은 그 목적지 경로에서 나옵니다. 규칙은 유효한 BGP 인코딩을 갖추었다는 이유만으로 수용되지 않습니다.

이 의존성은 동적입니다. RFC 8955는 대응하는 유니캐스트 경로가 바뀔 때마다 FlowSpec 검증을 반복하도록 요구합니다. 목적지가 다른 발기지로 옮겨가거나 다른 이웃을 통해 더 구체적인 경로가 나타나면, 이전의 조치 근거는 사라질 수 있습니다. 권한은 따라서 규칙의 영구 속성이 아니라 현재 토폴로지를 따라갑니다.

로컬 컨트롤러 문제

중앙집중식 제어는 한계를 드러냅니다. 운영자 자신의 도메인 안에 있는 컨트롤러는 영향을 받는 모든 프리픽스로 가는 최적 포워딩 경로 위에 나타나지 않으면서도 정당하게 완화 규칙을 배포할 수 있습니다. 엄격한 기본 검사 아래에서는 그 컨트롤러가 컨트롤러이지 전송 홉이 아니라는 이유만으로 유용한 규칙이 실패할 수 있습니다.

2021년 8월에 발표된RFC 9117은 바로 그 사례를 위해 RFC 8955를 갱신합니다. 저자는 Jeffrey Uttaro, Jorge Alcaide, Clarence Filsfils, David Smith, Pradosh Mohapatra이며, Susan Hares가 아닙니다. 이 후속 문서가 이 이야기에 들어오는 이유는 Hares가 공동 저술한 표준 이후 권한 경계가 어떻게 발전했는지를 보여주기 때문입니다.

완화는 범위가 정해져 있습니다. 같은 로컬 행정 도메인 안에서 운영자는 중앙 라우트 컨트롤러를 명시적으로 신뢰하고, 발기자가 포워딩 경로 위에 있다고 가정하는 발기지 검증을 건너뛸 수 있습니다. RFC 9117은 또한 라우트 서버가 보통의 전송 라우터처럼 행동하지 않으면서 FlowSpec 경로를 배포하는 경우의 AS 경로 처리를 명확히 합니다. 그러나 어떤 원격 컨트롤러도 보편적 필터링 권한을 갖게 되지는 않습니다. 수신 운영자가 의도적으로 다른 정책을 채택하고 위험을 감수하지 않는 한, 도메인 간 전파는 더 강한 검증 모델의 대상으로 남습니다.

이 경계는 자주 뒤섞이는 두 진술을 분리합니다. “이 장치는 우리 조직이 우리 네트워크를 프로그래밍하도록 승인했다”는 로컬 거버넌스 결정입니다. “이 이웃 네트워크는 내 네트워크에게 특정 목적지의 트래픽에 영향을 주도록 요청할 수 있다”는 도메인 간 조정 주장입니다. 첫째는 한 운영자가 설정할 수 있습니다. 둘째는 라우팅 상태에 대한 방어 가능한 관계와 명시적인 수신자 정책이 필요합니다.

조치는 유용성과 오류를 모두 확대한다

RFC 8955의 보안 논의는 이례적으로 실용적입니다. 완화된 검증은 원치 않는 필터링, 리마킹 또는 리디렉션을 허용할 수 있습니다. 비속도 조치는 포워딩을 바꾸거나, 트래픽을 다른 VPN 컨텍스트에 넣거나, 큐 처리를 변경할 수 있습니다. 고장 나거나 침해된 컨트롤러는 높은 업데이트 속도를 내보내거나, 플랫폼 용량을 초과하거나, 문법적으로는 옳지만 매치 결과가 재앙적인 규칙을 설치할 수 있습니다.

따라서 수신자는 합격/불합격 파서 이상이 필요합니다. 보더 정책은 일부 조치만 허용할 수 있습니다. 프리픽스와 포트 범위는 제약될 수 있습니다. 속도 한계, 리디렉션 타겟, 규칙 수에는 상한이 필요합니다. 라우트 서버 배포는 경로 속성이 직접 양측 EBGP와 같은 방식으로 권한을 표현하지 않을 수 있으므로 특별한 주의를 요구합니다. 하드웨어 용량도 문제입니다. BGP에 경로를 수용한 라우터조차 포워딩 테이블에는 설치하지 못할 수 있습니다.

RFC 발표는 이러한 운영적 사실 중 어느 것도 증명하지 않습니다. 벤더가 모든 구성 요소를 지원한다는 것, 운영자가 기능을 켰다는 것, 라우터 간 정책이 동등하다는 것, 완화가 성공했다는 것은 보여주지 않습니다. 표준은 상호 운용 가능한 의미와 기본 안전 논리를 정의할 뿐입니다. 실제 네트워크는 여전히 결과를 스스로 입증해야 합니다.

작은 문법과 로컬 결정면

Lu Heng의 에세이Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption은 유용한 분석 틀을 제공합니다. FlowSpec의 공유 계층은 좁게 유지될 수 있습니다. 공통 매치 구성 요소, 공통 조치 인코딩, 결정적 순서 지정, 유니캐스트 라우팅과의 기본 검증 관계입니다. 수신 네트워크는 미래의 결정면을 유지합니다. 수용할 피어, 허용할 조치, 컨트롤러 신뢰, 용량 한계, 로깅, 철회 정책입니다.

공유 문법이 중앙 권한으로 오해될 때 이 메커니즘은 위험해집니다. 모든 구현이 문법에 다른 의미를 부여할 때는 무력해집니다. 작동하는 중간 지점은 그 결과가 로컬에서 승인되고 관찰되는 작은 상호 운용 문법입니다.

Running-Code Primacy는 이 검사를 더 예리하게 만듭니다. 결정적 증거는 규칙이 컨트롤 플레인 테이블에 나타난다는 사실이 아닙니다. 운영자는 검증 상태, 선택된 규칙 순서, 포워딩 설치, 매치된 패킷 카운터, 실제 적용된 조치, 영향받은 서비스, 철회 및 복구를 확인해야 합니다. 유니캐스트 경로가 바뀔 때 무슨 일이 생기는지 시험해야 합니다. 권한을 다시 계산해야 하는 바로 그 순간이기 때문입니다. 이 후속 에세이들은 Sofia Ren의 해석적 렌즈이며, Hares나 RFC 저자들에게 귀속되는 입장이 아닙니다.

FlowSpec은 네트워크가 모든 중대 규칙에 대해 세 가지 질문에 답할 수 있을 때 가장 신뢰할 수 있습니다. 누가 발기했는가, 어떤 현재 라우팅 사실이 그 발기자에게 자격을 부여하는가, 어느 로컬 정책이 요청된 조치를 허용했는가. 문서 사슬에서 Hares가 차지하는 위치는 이러한 규율을 드러내는 데 도움을 줍니다. 필터는 강력해서가 아니라, 한계가 있고 철회 가능하며 현재 상태에 책임을 지는 방식으로 남을 때 행동할 권리를 얻습니다.

출처