요약

  • Randy Bush가 쓴 RFC 7115는 큰 주소 블록의 ROA를 발행하기 전에 다른 AS가 알리는 모든 하위 할당에 맞는 ROA가 있는지 확인하라고 요구한다. 고객 경로를 빠뜨리면 그 출처 검증 결과가 Invalid가 될 수 있다.
  • 검증된 데이터는 캐시에서 라우터로 전달되고, 각 네트워크의 로컬 정책이 판정 결과를 사용한다. Bush는 로컬 캐시를 포함한 복수 캐시와 정기 동기화도 권고했다.

부모의 서명이 고객의 경고등을 켠다

큰 IP 주소 블록의 보유자가 전체를 덮는 ROA를 발행하려 한다. 그 안에는 고객에게 넘겨준 더 작은 블록이 있고, 고객은 자기 AS에서 그 경로를 알린다. 서명이 캐시와 라우터에 도착해도 고객의 BGP 공지는 그대로다. 달라질 수 있는 것은 옆에 붙는 판정, Invalid다. 부모 블록을 가진 쪽의 서류가 고객 쪽 경로의 신호등을 바꾼다.

Bush는 RFC 7115에 발행 전 순서를 명시했다. 2014년 발표된 이 Best Current Practice 문서는 큰 상위 블록의 ROA를 내기 전에 다른 AS가 알리는 모든 하위 할당, 특히 고객의 할당에 올바른 ROA가 있는지 확인하라고 한다. 빠진 고객 공지는 Invalid로 보일 수 있다. 고객들이 각자 등록을 끝낼 때까지는 실제 BGP 자료를 토대로 임시 ROA를 마련하는 방법도 제시한다. 큰 도장을 찍기 전에 작은 주소들을 세라는 뜻이다.

RFC 6811은 판정의 계산법을 설명한다. 공지된 접두사와 출처 AS를 검증된 ROA 데이터와 비교해 Valid, NotFound, Invalid 가운데 하나를 낸다. 상위 ROA가 생기면 고객의 더 구체적인 공지는 출처나 허용 길이 조건과 어긋날 수 있다. 그 결과를 라우팅에 어떻게 쓰는지는 각 망의 로컬 정책이다. Invalid 경로를 거부하는 망에서는 빠진 고객 명단이 연결성 문제로 이어진다.

Bush가 Rob Austein과 함께 쓴 RFC 6810은 검증 캐시가 출처 데이터를 라우터에 전하는 통로를 규정한다. RFC 7115는 라우터가 둘 이상의 캐시에 연결하고 적어도 하나는 로컬에 둘 것을 권고한다. 라우팅 결정에 쓰는 로컬 캐시는 서로 적어도 네 시간에서 여섯 시간마다 동기화해야 한다. 상위 사업자의 캐시에서 받은 데이터는 수신자가 다시 검증해야 한다. 한 번의 ROA 발행은 이 경로를 따라 여러 운영자의 정책과 만난다.

RIPE NCC의 Bush 소개에는 라우팅 보안, RPKI, 출처 검증에서 이어온 그의 활동이 적혀 있다. 그래서 RFC 7115의 핵심은 암호 기술의 찬사가 아니라 작업 순서다. 본문의 편집 초상은 RIPE NCC가 이름을 붙인 사진을 인물 기준으로 삼았다. 뒤의 두 장비 캐비닛은 상상한 배경이다.

운영실에서 필요한 것은 고객별 접두사, 공지 AS, ROA를 한 줄에 놓은 목록이다. 한 줄이 빠지면 다른 망의 라우터가 그 고객을 다르게 판정할 수 있다. Bush는 이 평범한 목록을 발행 전 안전장치로 만들었다.