MANRS는 모든 경로의 ROA를 원한다. 레거시 자원이 규칙을 시험한다

요약

Andrei Robachevsky는 RIPE 93에서 ROV를 MUST로 두고 MANRS 참여자가 광고하는 모든 프리픽스에 유효한 ROA를 요구하는 작업반 제안을 설명했다.
운영자가 직접 증명을 만들 수 없는 경우도 있다. ARIN과 계약하지 않은 레거시 자원 보유자는 ARIN RPKI에 접근할 수 없고, 프리픽스를 빌린 고객이 ROA를 만들지 않을 수도 있다.

분석

BGP 경로를 광고하는 쪽과 그 경로의 권한을 등록하는 쪽이 다를 수 있다. MANRS의 “RPKI 100%” 제안은 그 둘을 하나의 감사 항목으로 묶을 수 있는지 묻는다.

10월 27일 RIPE 93에서 Robachevsky는 MANRS 네트워크 운영자 프로그램 검토 작업반의 진행 상황을 설명했다. 2014년 출범 뒤 네트워크 운영자 행동 규칙은 실질적으로 크게 개정되지 않았다. 작업반은 요구사항과 이행·감사 안내를 분리하고, IETF의 MUST·MUST NOT 같은 규범 용어를 써서 해석 차이를 줄이려 했다. 그가 소개한 초안에서는 ROV가 MUST, IRR 등록이 SHOULD였다. 라우팅 정보 조치와 관련해 참여자가 광고하는 모든 프리픽스에 유효한 ROA를 두는 완전한 RPKI 커버리지를 논의 중이었다.

당시 이 내용은 확정된 MANRS 규칙이 아니었다. Robachevsky는 작업반 내부의 최종 검토 뒤 커뮤니티 의견 수렴을 진행할 예정이라고 했다. 현재 참여자만의 합의로 끝내지 않고 더 넓은 커뮤니티의 의견을 받으려는 절차였다. RIPE의 공식 녹취록은 제안과 미결 쟁점을 구분해 보여 준다.

MANRS가 3월 공개한 설문에는 38명이 답했다. 대부분 네트워크 운영자였고, 요구사항을 더 분명하게 만들고 감사 기준을 명확히 하자는 의견이 우선했다. 응답자의 절반은 검토 우선순위로 네트워크 운영자 프로그램을 꼽았다. 공개 페이지에는 초대 대상자 수가 없어 응답률은 계산할 수 없다.

RPKI 이용 여부는 기술만의 문제가 아니다. ARIN은 계약을 맺지 않은 레거시 자원 보유자가 ARIN의 RPKI와 IRR 서비스를 이용할 수 없다고 설명한다. 계약을 체결한 보유자는 서비스를 쓸 수 있다. 또한 ROA는 자원 보유자의 리소스 인증서에 포함된 자원만 대상으로 삼을 수 있다. 다른 회사의 프리픽스를 광고하는 운영자가 자기 인증서로 대신 ROA를 발급할 수는 없다.

Robachevsky는 두 가지 사례를 들었다. ARIN 지역의 일부 레거시 보유자는 RPKI에 접근하지 못하고, 운영자가 광고하는 고객 임대 프리픽스에는 고객이 ROA를 만들지 않은 경우가 있다. 경로를 운용하는 책임은 통신사에 있지만 등록 절차는 고객이나 자원 보유자가 통제할 수 있다. 감사 결과의 미준수 표시는 통제권이 없는 운영자에게 붙을 수 있다.

IRR도 초안에 남아 있었다. 다만 IRR은 SHOULD, ROV는 MUST로 나뉘었다. 여전히 IRR을 사용하는 운영자가 있고 어떤 레지스트리와 객체를 인정할지 검토 중이었다. IRR 항목을 RPKI의 완전한 대체재로 취급하면 작업반이 제안한 우선순위가 사라진다. IRR을 무시하면 운영자가 경로를 설명하고 필터를 구성할 때 쓰는 현실의 도구가 빠진다.

Robachevsky에 따르면 MANRS는 2014년 9개 운영자에서 발표 당시 약 1,400개 참여자로 성장했다. 기준의 가치는 소수에게 가장 높은 점수를 주는 데 있지 않고 더 많은 네트워크가 최소 기준을 채택하는 데 있다. 자원 소유 관계가 복잡한 네트워크를 규칙이 밀어내면 남은 회원의 준수율은 높아져도 실제 커버리지는 줄어들 수 있다.

그러므로 “100%”를 규칙으로 쓰기 전에 네 가지를 정해야 한다. 어떤 광고가 대상인지, ROA를 누가 만들어야 하는지, 고객이나 자원 보유자가 등록을 통제할 때 어떻게 처리할지, 기존 참여자에게 얼마의 이행 기간을 줄지다. 이 답 없이 감사만 강화하면 책임 소재만 바뀌고 빠진 권한 증명은 생기지 않는다.