라우팅 신뢰, AI 제어 루프(Control Loops), 그리고 물리적 에지(Physical Edge)

7월의 네트워킹 이야기는 하나의 깔끔한 서사로 정의되지 않았습니다. 오히려 더 복잡했는데, 이는 보통 더 유용하다는 것을 의미합니다. 이번 달에는 BGP와 DNS 관련 작업들이 있었는데, 인터넷의 상당 부분이 이러한 '지루한 것들'이 정확하게 작동하는 것에 여전히 의존하고 있다는 점을 상기한다면 결코 지루하지 않은 작업들이었습니다. 또한 AI 인프라 업데이트들도 있었는데, 이를 패브릭(fabric), 텔레메트리(telemetry), ID(identity), 그리고 폭발 반경(blast radius)까지 추적해 보면 단순한 플랫폼 뉴스처럼 들리지 않았습니다. 무선 및 에지(edge) 관련 이야기들도 있었는데, 여기서 흥미로운 점은 새로운 라디오 장비가 아니라 날씨, 곤충, 공공 안전 제약 조건, 그리고 까다로운 경제적 상황이 존재하는 곳에서 물리적 네트워크를 작동시키는 데 드는 비용이었습니다.

나의 견해: 7월은 제어 루프(control loops)에 관한 달이었습니다. 라우팅 검증(Routing validation)은 제어 루프입니다. AI 관측성(AI observability)은 제어 루프입니다. 클라우드 검사(Cloud inspection)는 제어 루프입니다. Wi-Fi 자동화는 제어 루프입니다. 설계 검토(design review) 시 던져야 할 질문은 "컨트롤러가 의도(intent)를 가지고 있는가?"가 아닙니다. "현실과 일치하지 않을 때, 시스템이 네트워크에 대한 자신의 관점이 최신 상태이고, 경계가 정해져 있으며, 가역적(reversible)임을 증명할 수 있는가?"입니다.

나는 패킷 캡처(packet captures)와 트러블슈팅(troubleshooting) 시스템 주변에서 많은 시간을 보내기 때문에, 타임스탬프(timestamps), 오래된 토폴로지(stale topology), 비대칭 경로(asymmetric paths), DNS 소유권(DNS ownership), RPKI 상태(RPKI state), 그리고 인간이 여전히 장애 영역(failure domain)을 이해할 수 있는지 여부와 같이 화려하지 않은 부분들에 편향되어 있습니다. 7월은 그러한 편향에 보답하는 달이었습니다. 다음은 내가 계속 가져가고자 하는 내용들입니다.

이번 달의 주요 변화

인터넷 코어(Internet core)는 "레거시(legacy)"가 선택 사항이 아님을 모두에게 계속해서 상기시켜 주었습니다. 매달린 DNS 레코드와 역방향 DNS 격차(dangling DNS records and reverse DNS gaps)에 대한 Network World의 분석이 좋은 예시였습니다. 이름을 도달 가능한 리소스로 변환하는 도메인 네임 시스템 (DNS, Domain Name System)은 여전히 너무 많은 조직에서 관리용 배관 작업(admin plumbing)처럼 취급되고 있습니다. 그러면 잊혀진 레코드, 오래된 위임(stale delegation), 또는 역방향 조회(reverse lookup)의 격차가 상위 계층이 이미 깨끗하다고 가정하는 신뢰 결정(trust decisions)으로 침투하는 공격자 제어 경로가 됩니다. APNIC의 IETF 126의 BGP 주제들(BGP topics from IETF 126)과 중국이 ROA를 배포했다(China rolled out ROAs)는 MANRS/Kentik의 언급과 함께 라우팅 측면에서 동일한 점을 강조했습니다. 경계 관문 프로토콜 (BGP, Border Gateway Protocol)은 여전히 인터넷의 도메인 간 라우팅 프로토콜이며, 더 많은 경로 기원 인증 (ROA, Route Origin Authorizations)이 존재한다고 해서 그 안전 작업이 끝난 것은 아닙니다.

AI 인프라는 모델 중심의 이야기에서 운영 중심의 이야기로 변하고 있습니다. Google Cloud의 AI 인프라 및 오케스트레이션 요약(AI infrastructure and orchestration roundup), AI 인프라로 전환되는 관측성(observability pivoting toward AI infrastructure)에 관한 Network World의 기사, 그리고 프런티어 AI를 위한 Cisco의 제로 트러스트 프레임워크(Zero Trust framing for frontier AI)는 모두 동일하고 불편한 진실을 가리키고 있습니다. 에이전트 군단(Agent fleets), GPU 클러스터, 그리고 AI 제어 평면 (AI control planes)은 네트워크 작업을 없애지 않습니다. 오히려 네트워크를 애플리케이션의 추론 루프 (reasoning loop)의 의존성으로 만듭니다. 만약 텔레메트리 (telemetry)가 지연되거나, 식별 (identity)이 너무 거칠거나, 혹은 지난 화요일에 라우팅 테이블이 수동으로 편집되었다면, 에이전트는 마법 같은 존재가 되지 않습니다. 대신 더 빠르게, 확신에 찬 채로 틀리게 됩니다.

에지는 줄어든 것이 아니라, 더 물리적으로 변했습니다. Light Reading의 말레이시아 Starlink direct-to-cell 시험, 통신사 2분기 지표 비판, 그리고 브로드밴드 외부 설비(outside-plant) 수익 전망은 Cisco의 실외 Wi-Fi 7 제안과 나란히 배치되었으며, 솔직히 말해 이번 묶음 중 운영자에게 가장 현실적인 게시물은 Reddit의 Meraki 실외 액세스 포인트(AP)에 말벌이 생기지 않게 하는 방법에 관한 스레드였습니다. 이것이 7월을 한 문장으로 요약한 모습입니다. 위성-대-휴대폰 시험과 AP 위의 말벌은 모두 네트워킹 문제입니다. 이번 달의 형세는 명확했습니다. 상위 수준의 자동화가 도래하고 있지만, 그 기저(substrate)에는 여전히 RF, 전력, 정책, DNS, BGP, 그리고 실외 인클로저(enclosures)가 존재합니다.

1. 라우팅 신뢰는 등록(Registration)에서 동작(Behavior)으로 이동하고 있습니다

라우팅 보안은 실질적인 한 달을 보냈습니다. APNIC의 IETF 126의 BGP 주제는 BGP ORIGIN, ASPA, PAVA, 그리고 ASRA 작업을 다루었습니다. 매일 이 분야에서 활동하지 않는다면, BGP ORIGIN 검증(origin validation)은 자율 시스템(AS)이 특정 프리픽스(prefix)를 생성할 권한이 있는지 묻는 것이며, ASPA 작업은 제공자-고객(provider-customer) 관계를 기계가 더 잘 확인할 수 있도록 만드는 것을 목표로 합니다. 중요한 변화는 "레지스트리에 객체가 있는가?"에서 "특정 정책 하에서 네트워크가 실제로 무엇을 수락, 거부 또는 유출(leak)할 것인가?"로의 전환입니다.

Cloudflare가 BGP ORIGIN attribute manipulation에 대해 분석한 내용은, 트랜짓 제공업체(transit providers)들이 경로의 상당 부분을 ORIGIN 재작성으로 본다는 주장을 통해 이를 구체화했습니다. 이는 중요한 문제입니다. 왜냐하면 경로 선택은 운영자들이 무언가 이상이 발생하기 전까지는 거의 생각하지 않는 다수의 동점 처리 규칙(tie-breakers)들로 가득 차 있기 때문입니다. 만약 제공업체가 최적 경로 선택에 영향을 미치는 속성(attribute)을 변경할 수 있다면, 문제를 해결하기 시작하기도 전에 해당 경로가 승리한 이유에 대한 당신의 정신 모델(mental model)이 틀릴 수 있습니다. 제가 접해본 모든 BGP 누출 도구(BGP leak tool)는 결국 깔끔한 프로토콜 다이어그램과 지저분한 인터넷이 실제로 선택하는 경로 사이의 이러한 격차에 부딪힙니다.

MANRS/Kentik에서 중국이 ROA를 출시하는 것에 대해 다룬 글은 좋은 소식이지만, 저는 이것을 '라우팅 보안 문제가 해결되었다'고 읽지 않을 것입니다. 경로 원본 승인(Route Origin Authorizations, ROA)은 리소스 공개 키 인프라(Resource Public Key Infrastructure, RPKI)가 접두사(prefix)의 원본이 유효한지 알려주는 데 도움을 줍니다. 하지만 이것이 모든 상위 업스트림(upstream) 필터링이 올바르게 작동한다는 것, 경로 서버들이 예상하는 방식으로 동작한다는 것, 또는 다음 장애 발생 시 당신의 검증 경계(validation boundary)를 존중할 것이라는 것을 의미하지는 않습니다. 운영상의 요구사항은 더 지루합니다. 즉, 시행 전에 검증 영향을 측정하고, 예외 처리 방식을 명시적으로 유지하며, 레지스트리 진행 상황이 경로 가시성(path observability)을 대체하게 두지 않는 것입니다.

2. DNS 및 웹 기본값은 여전히 보안 인프라이다

7월의 DNS 관련 기사들은 AI만큼 화려하지 않았지만, 저는 이것들을 실제 위험 지표로 더 신뢰합니다. Network World의 느슨한 DNS 레코드와 역방향 DNS 격차 같은 글은 플랫폼 팀들이 계정 수명 주기 체크리스트를 열어보게 해야 하는 종류의 게시물입니다. 오래된 CNAME, 고아가 된 서브도메인(orphaned subdomain), 버려진 클라우드 서비스, 또는 일관성 없는 역방향 DNS 영역(reverse DNS zone)은 대시보드가 이를 사고로 간주하지 않기 때문에 몇 달 동안 조용히 존재할 수 있습니다. 그러다가 누군가가 그것을 발견하고 오래된 명명 규칙 위생(naming hygiene)을 능동적인 공격 표면으로 만듭니다.

APNIC의 IETF 126에서의 DNS 주제들은 리졸버 동작(resolver behavior), 양자 내성 DNSSEC (post-quantum DNSSEC), 낙관적 DNS (optimistic DNS), 그리고 위임 자동화 (delegation automation)를 통해 논의의 틀을 확장했습니다. DNSSEC은 DNS 데이터를 서명하기 위한 DNS 보안 확장 (DNS Security Extensions) 메커니즘입니다. 여기서 양자 내성 (post-quantum) 작업은 추상적인 암호학적 미래주의가 아닙니다. 더 커진 서명, 달라진 검증 동작, 그리고 리졸버의 예외 케이스(edge cases)들은 결국 지연 시간(latency), 파편화(fragmentation), 또는 기이한 타임아웃 패턴으로 나타납니다. 어떤 마이그레이션(migration)을 수행하기 전에 제가 해보고 싶은 지루한 테스트는 간단합니다. MTU, 미들박스(middleboxes), 그리고 UDP 처리가 이미 한계치에 도달한 경로들에서 가장 큰 서명된 응답(signed answers)들에 어떤 일이 발생하는가 하는 점입니다.

HSTS 강제를 통한 HTTP의 오래된 백도어 폐쇄에 관한 APNIC의 글은 또 다른 기본값(defaults)에 관한 이야기입니다. HTTP Strict Transport Security (HSTS)는 브라우저에게 HTTPS를 사용하도록 지시하지만, 현재의 웹에는 여전히 역사적인 다운그레이드(downgrade) 잔재가 남아 있습니다. 오래된 기본값을 반전시키는 것은 깔끔하게 들리지만, 롱테일 도메인(long-tail domains), 잊혀진 리다이렉트(redirects), 오래된 TLS를 사용하는 어플라이언스(appliances), 그리고 여전히 80번 포트가 무해하다고 가정하는 모니터링 프로브(monitoring probes)를 마주하게 되면 이야기가 달라집니다. 저는 이 방향성이 마음에 듭니다. 다만 "리다이렉트만 수행한다"는 이유로 아무도 패치하지 않은 까다로운 엔드포인트(endpoints)들을 먼저 전수 조사하지 않고는 이 정책을 배포하지 않을 것입니다.

3. AI 패브릭(AI Fabrics)에는 보여주기식 연출이 아닌 네트워크 상태(Network State)가 필요하다

AI 인프라 뉴스들은 네트워크를 플랫폼 언어 속으로 사라지게 만들려고 계속 시도합니다. 하지만 그럴 수 없습니다. Google의 AI 인프라 및 오케스트레이션 업데이트와 Network World의 Groundcover의 AI 인프라 관측성(Observability) 투자 유치 보도는 모두 완료된 애플리케이션을 모니터링(Monitoring)하는 것에서 상태(State)를 계획, 실행 및 변이(Mutate)하는 시스템을 감독(Supervising)하는 것으로의 전환을 반영했습니다. 이는 네트워크가 단순히 트래픽을 운반하는 것이 아니라, 무엇이 존재하는지에 대한 모델의 관점(View)에 데이터를 공급하고 있음을 의미합니다.

이 지점이 바로 제가 일반적인 "AI ops" 주장들에 회의적인 이유입니다. 경고(Alerts)를 요약할 수 있는 에이전트(Agent)는 유용합니다. 하지만 네트워크 상태를 변경할 수 있는 에이전트는 자신이 어떤 토폴로지 스냅샷(Topology snapshot), 라우팅 테이블(Route table), 보안 정책(Security policy), 그리고 패킷 증거(Packet evidence)를 사용하고 있는지 알지 못한다면 위험합니다. Google Cloud의 GKE 에이전트 샌드박스 비용 절감 주장과 AI 에이전트를 위한 AlloyDB 그룹 인증은 적어도 리소스 경계와 아이덴티티 규모(Identity scale)를 인정하고 있다는 점에서 흥미롭습니다. 하지만 실패 모드(Failure mode)는 단순히 비용이나 로그인 확산(Login sprawl)의 문제가 아닙니다. 그것은 누구도 최신성(Freshness)과 최소 권한(Least privilege)을 네트워크 모델의 일부로 만들지 않았기 때문에, 에이전트가 오래된(Stale) 정보나 지나치게 광범위한 권한을 바탕으로 작동하는 것입니다.

Cisco의 Zero Trust Imperative for the Frontier AI Era 또한 같은 범주에 속합니다. 제로 트러스트 (Zero Trust)는 집행 지점 (Enforcement points)이 좁은 범위의 결정을 내릴 수 있을 만큼 충분한 컨텍스트 (Context)를 파악할 수 있을 때만 유용합니다. AI 시스템의 경우, 이는 사용자, 서비스, 에이전트 (Agents), 도구 (Tools), 그리고 데이터 액세스 경로 (Data access paths)에 대한 신원 (Identity)을 의미합니다. 만약 이러한 경로가 VPC 경계, SaaS 통합, 프라이빗 데이터베이스, 그리고 외부 API를 가로지른다면, 패킷 경로 (Packet path)가 중요해집니다. 저는 변경 전 토폴로지 (Topology)를 바탕으로 추론했는지 변경 후 토폴로지를 바탕으로 했는지조차 구분하지 못하는 세련된 챗봇보다는, 패킷 타임스탬프 (Packet timestamps)가 포함된 지루한 증거 그래프 (Evidence graph)를 갖는 편이 낫습니다.

4. 클라우드 네트워킹은 실질적인 힘을 가진 정책 배관 (Policy Plumbing)이 되고 있다

7월의 클라우드 네트워킹 업데이트는 단순히 더 보기 좋은 추상화 (Abstractions)에 관한 것이 아니었습니다. AWS의 Amazon VPC Route Server 및 Transit Gateway를 활용한 중앙 집중식 VPC 검사 (Centralized VPC inspection with Amazon VPC Route Server and Transit Gateway)는 유용한 복잡성의 전형적인 사례입니다. 중앙 집중식 검사는 중복된 방화벽 스택 (Firewall stacks)을 줄이고 집행 (Enforcement)을 더 쉽게 추론할 수 있게 만듭니다. 하지만 이는 또한 비대칭 라우팅 (Asymmetric routing), 경로 전파 타이밍 (Route propagation timing)에 대한 숨겨진 의존성, 그리고 스포크 VPC (Spoke VPC)가 경로를 가지고 있다고 생각하지만 검사 정책이 이를 조용히 변경해 버릴 때 발생하는 혼란스러운 장애 도메인 (Failure domains)을 생성할 수도 있습니다.

Amazon의 CloudWatch용 관리형 Prometheus 수집기 (managed Prometheus collectors for CloudWatch) 또한 보기보다 네트워킹과 더 밀접한 관련이 있습니다. Prometheus 메트릭 (metrics)은 장애 발생 시 컨테이너, 로드 밸런서 (load balancer), DNS, 그리고 서비스 레벨 (service-level)의 동작을 상관 분석 (correlate)할 수 있는 유일하고 실질적인 방법인 경우가 많습니다. 관리형 수집기 (managed collector)는 운영상의 노고 (operational toil)를 제거해 주지만, 동시에 신뢰 경계 (trust boundary)를 추가합니다. 즉, 스크레이프 설정 (scrape configuration), 카디널리티 폭발 (cardinality blowups), 보존 (retention), 그리고 수집기는 정상인데 애플리케이션 경로 (application path)는 정상이지 않은 시점의 소유권은 누구에게 있는가 하는 문제입니다. 메트릭 수집 (Metrics collection) 그 자체가 관측성 (observability)은 아닙니다. 그것은 잘못된 경로를 설명하는 데 필요한 토폴로지 (topology)와 타이밍 (timing)을 보존할 때에만 유용합니다.