요약

  • Invalid에서 Valid로 바뀐 뒤 측정 지점 절반의 도달 가능성이 회복되는 데 걸린 중간값은 멀티홈 9분, 단일 업스트림 12분이었다.
  • Valid에서 Invalid로 바뀌면 순서가 뒤집혔다. 측정 지점 절반이 도달성을 잃기까지 멀티홈은 42분, 단일 업스트림은 30분이 걸렸다.

업스트림 두 개는 경로를 빨리 되돌릴 수도, 늦게 사라지게 할 수도 있다. 중복 연결이 모순을 만든 것은 아니다. 각 업스트림이 자기 검증기와 자기 갱신 주기를 갖고 있기 때문이다.

이 수치는 RIPE 93에서 발표된 RPKI 상태 변경과 데이터 평면 도달성 측정에서 나왔다. 연구진은 RIPE 저장소에서 검증 페이로드를 바꾼 약 2만5천 건의 변경을 추적한 뒤, 한 번의 상태 전환을 관찰하기 적합한 약 1,500건을 따로 분석했다. VRP 변경을 감지하면 300개가 넘는 CAIDA Ark 노드에서 traceroute를 시작해 약 3분 간격으로 한 시간 동안 관찰했다.

잰 것은 ROA를 수정한 시각도, 첫 검증기가 객체를 내려받은 시각도 아니었다. 측정 지점의 절반이 프리픽스에 다시 도달하거나 더는 도달하지 못한 시점이었다. 저장소의 게시, 검증기의 수집, 라우터의 처리, 실제 패킷 전달은 각자 다른 시계를 따른다.

Valid로 돌아올 때는 두 번째 길이 도움이 된다

Invalid에서 Valid로 바뀐 뒤 절반의 관측 지점에서 도달성이 회복되기까지 중간값은 멀티홈 네트워크 9분, 단일 업스트림 네트워크 12분이었다. 각 사업자는 서로 다른 relying-party 소프트웨어와 갱신 주기를 운용한다. 독립된 업스트림이 두 곳이면 한쪽이 새 객체를 먼저 받아 처리할 가능성이 커진다.

멀티홈 그룹에서는 늦게 반응하는 구간도 더 짧았다. 이점은 연결이 많다는 사실 자체보다 업데이트 경로가 서로 독립적이라는 데서 나온다. 한쪽이 새 권한을 먼저 반영하면 다른 쪽이 다음 수집 주기를 기다리는 동안에도 경로가 돌아올 수 있다.

두 번째 업스트림이 ROA를 유효하게 만드는 것은 아니다. ROA는 출발 AS에 대한 권한을 선언하고, 검증기는 공개 객체를 바탕으로 상태를 계산한다. 측정된 차이는 그 다음 단계, 즉 업스트림과 라우터가 새 상태를 적용하는 구간에서 생겼다.

Invalid가 되면 출구 쪽 대기열이 길어진다

Valid에서 Invalid로 바뀌자 결과는 반대였다. 절반의 측정 지점이 도달성을 잃기까지 단일 업스트림은 중간값 30분, 멀티홈은 42분이었다. 한 업스트림이 RPKI 상태를 갱신해 경로 처리를 바꿔도 다른 쪽 검증기가 아직 옛 상태를 보고 있다면 그 경로를 계속 알릴 수 있다. 백업 경로가 이번에는 퇴장 시간을 늘린다.

장애 대응에서 Invalid는 전 세계 공통의 전원 스위치가 아니다. 각 네트워크는 자기 정책으로 잘못된 경로 광고를 처리하고, 검증기도 한꺼번에 갱신되지 않는다. 어딘가에서 광고가 계속되는 동안 BGP는 선택할 경로를 갖는다. 관리 화면이 상태 변경을 보여준 뒤에도 일부 traceroute가 프리픽스에 도착할 수 있다.

연구는 단일 출발지 사례를 측정했고, 더 구체적인 커버 경로가 있는 사례는 제외했다. traceroute 관찰은 한 시간 뒤 끝났다. 따라서 9분, 12분, 30분, 42분은 이 표본에서 관찰한 중간값이다. 운영팀이 확인할 일은 어느 업스트림이 새 상태를 적용했고 어느 곳이 아직 경로를 광고하는지다.

ROA 변경 뒤에는 여러 개의 시계가 돈다

ROA를 바꾼 뒤 실제 전달 결과가 달라지기까지 저장소 게시, 검증기 수집과 검사, 라우터에 상태 전달, 로컬 정책 적용, 데이터 평면 수렴이 이어진다. “RPKI 업데이트 완료”라는 한 줄은 작업 티켓에는 편하지만, 네트워크가 언제 달라졌는지는 알려주지 않는다.

연구진은 RIPE 저장소의 원본 측 신호를 관찰하고 최적화한 검증기를 사용했다. 발표자는 비교 대상인 공개 검증기보다 최소 57초, 중간값으로는 5분 먼저 변화를 감지했다고 설명했다. 덕분에 많은 네트워크가 반응하기 전에 traceroute를 시작할 수 있었다. 이는 측정 방법의 장점이며 외부 검증기의 일정을 RIPE NCC가 통제한다는 뜻은 아니다.

발표자는 사고 전에 ROA를 만들어 두고 검증기 수집 간격을 살피며 소프트웨어가 지원하면 RRDP를 쓰라고 권했다. 제안한 수집 간격은 5~10분이었다. 실제 수정의 영향을 확인하려면 게시 시각, 검증기별 관측, 업스트림 상태, 독립 탐침의 도달성 결과를 함께 남겨야 한다. 초록색 배지 하나로는 이 네 시계를 대신할 수 없다.

출처: RIPE 93 공식 세션과 초록; RIPE 93 전체회의 공식 기록; RFC 6811: BGP 프리픽스 기원 검증.