리소스 공개 키 기반 구조(RPKI)는 어떻게 작동하는가

서비스를 새 네트워크로 옮겼다고 합시다. 서버는 정상이고 주소도 그대로인데, 일부 방문자는 더 이상 접속하지 못합니다. 원인은 의외로 작은 데 있을 수 있습니다. 인터넷의 라우팅 기록이 여전히 이전 네트워크에만 그 주소를 알릴 권한을 부여하고 있는 것입니다.

RPKI는 이 권한을 다른 네트워크가 확인할 수 있는 형태로 만듭니다. 여기서는 그 권한이 주소 보유자에게서 라우터까지 전달되는 과정을 살펴봅니다. 아울러 이 체계를 계속 작동시키는 일이 특정 관리자 한 곳의 권한 유지에 달려 있어서는 안 된다는 루헝의 주장도 다룹니다. 더 짧은 설명을 원한다면 RPKI가 보호하는 것부터 읽어 보세요.

1. 누가 주소에 대한 권한을 부여할 수 있는지 확인하기

IP 주소의 묶음을 프리픽스라고 합니다. 그 프리픽스를 알리는 네트워크는 자율 시스템 번호, 즉 ASN으로 자신을 식별합니다. 리소스 공개 키 기반 구조(Resource Public Key Infrastructure, RPKI)는 인증서를 사용해 특정 주소 범위에 대한 권한을 누가 부여할 수 있는지 확인합니다.

인증서는 신뢰하는 루트까지 이어지는 체인을 이룹니다. 이 계층은 RFC 6480에 설명된 인터넷 번호 자원의 할당 체계를 따릅니다. 이는 해당 체계 안에서 자원에 관한 근거를 제공합니다. 인증 기관에 인터넷 이용자를 지배할 정치적 권한을 주는 것은 아닙니다.

2. 서명된 권한 정보 게시하기

주소 보유자는 경로 기원 권한 부여(Route Origin Authorisation, ROA) 정보를 게시합니다. 그 내용은 구체적입니다. 이 ASN이 이 프리픽스의 경로를 기원할 수 있다는 뜻입니다. 여기서 기원이란 공표된 경로의 출발점인 네트워크를 말하며, 이후 트래픽을 운반하는 모든 네트워크를 뜻하지는 않습니다.

ROA에는 최대 프리픽스 길이도 지정할 수 있습니다. 주소 범위를 얼마나 작은 범위까지 나누어 알릴 수 있는지를 정하는 값입니다. 이 선택 항목을 설정하지 않으면 명시된 프리픽스 길이만 허용합니다. 따라서 ‘이 범위에 대한 권한’이 모든 가능한 세분화에 대한 권한으로 묵시적으로 확대되지 않습니다. 서명된 기록의 형식은 RFC 9582에서 정의합니다.

3. 게시된 기록을 검증된 데이터로 바꾸기

서명된 기록은 게시 저장소를 통해 제공됩니다. 검증 소프트웨어는 이를 수집해 인증서 체인, 서명, 만료 및 폐기 정보를 확인하고, 게시된 객체 목록을 설명하는 매니페스트도 검사합니다. 파일을 읽을 수 있다는 것만으로는 충분하지 않습니다. 그 파일을 뒷받침하는 근거도 검증을 통과해야 합니다.

검증기는 실제로 사용할 수 있는 권한 데이터를 만듭니다. 이를 흔히 검증된 ROA 페이로드(Validated ROA Payloads, VRP)라고 부릅니다. 여기에는 프리픽스, 허용된 기원 ASN, 최대 길이가 들어 있습니다. 라우터는 RFC 8210에 설명된 RPKI-to-Router 프로토콜을 통해 신뢰하는 캐시로부터 결과를 받습니다. 방문자가 페이지를 열 때마다 등록 기관에 허가를 요청하는 것이 아닙니다.

4. 경로와 권한 비교하기

BGP는 네트워크끼리 경로를 알리는 데 사용하는 프로토콜입니다. 경로를 받은 라우터는 그 경로의 프리픽스와 기원 ASN을 검증된 권한 데이터와 비교합니다. 이것이 경로 기원 검증(Route Origin Validation, ROV)입니다.

Valid(유효): 프리픽스를 포함하는 권한 중 기원과 프리픽스 길이를 모두 허용하는 것이 있습니다. Invalid(유효하지 않음): 프리픽스를 포함하는 권한은 있지만, 해당 조합을 허용하는 것은 없습니다. NotFound(찾을 수 없음): 프리픽스를 포함하는 권한이 없습니다. 이는 비교 결과이며, 누군가의 의도를 판단한 결론이 아닙니다. 운영자는 이 결과를 라우팅 정책에 어떻게 사용할지 결정합니다. RFC 6811을 참고하세요.

서비스 이전 사례로 돌아가 보겠습니다. 이전 ASN에는 여전히 권한이 있고 새 ASN에는 없다면, 새 경로 공표는 Invalid로 판정될 수 있습니다. Invalid 경로를 필터링하는 네트워크는 이를 거부할 수 있습니다. 해결하려면 두 네트워크 모두에 권한이 필요한 기간까지 고려해 권한 변경과 서비스 이전을 조율해야 합니다. 서버가 정상이라는 이유만으로 접속 가능성이 보장된다고 가정해서는 안 됩니다. 운영상 주의 사항은 RFC 7115에서 다룹니다.

5. 전체 체인이 계속 작동하도록 관리하기

기원 검증은 거짓 기원 주장을 거부하는 데 도움이 됩니다. 하지만 모든 홉을 검증하거나 트래픽을 암호화하지 않으며, 모든 경로 유출을 잡아내지도 못합니다. 경로가 유출되어도 기원은 허가된 상태로 남을 수 있습니다. 다른 라우팅 보호 수단도 여전히 필요합니다.

검증 근거 역시 관리해야 합니다. 인증서는 만료되고, 권한과 게시 데이터는 바뀝니다. ROA를 삭제한다고 반드시 즉시 장애가 발생하는 것은 아닙니다. 최종 검증 결과는 다른 가용 기록에 따라 달라지며, 라우팅에 미치는 영향은 각 운영자의 정책에 달려 있습니다. RFC 8211은 인증 기관과 저장소 운영자의 오류 또는 불리한 조치가 시스템에 어떤 영향을 줄 수 있는지 살펴봅니다.

루헝의 제안: 서비스는 보존하고 관리자는 교체할 수 있게 하자

루헝은 노트 70에서 익숙한 논리적 비약에 이의를 제기합니다. 등록 서비스가 필수적이라는 이유로 현재 운영자도 대체 불가능해야 한다는 주장입니다. 네트워크에는 정확한 기록과 제대로 작동하는 보안이 필요합니다. 그렇다고 특정 기관에 네트워크를 영구히 통제할 권리가 생기는 것은 아닙니다.

그가 제안하는 대안은 연속성을 시스템 자체의 속성으로 만드는 것입니다. 독립적으로 감사할 수 있는 기록, 적격 후임자에게 넘기는 검증된 인계 절차, 네트워크의 주소 변경을 강제하지 않으면서 관리 주체를 옮길 방법이 필요합니다. 그는 디렉터리를 복사하는 것만으로 RPKI를 이전할 수 없다는 점을 분명히 인정합니다. 전환하는 내내 키, 인증서, 게시 체계, 신뢰 관계가 서로 일관성을 유지해야 합니다.

이는 그가 요구하는 설계 요건이지, 이런 이동성이 이미 어디서나 제공된다는 주장이 아닙니다. 이 요건은 문제의 양면을 함께 다룹니다. 부주의하게 교체하면 검증이 중단될 수 있고, 교체할 수 없는 문지기는 그 의존 관계를 권력으로 바꿀 수 있습니다. 믿고 쓸 수 있는 서비스와 교체 가능한 관리자를 함께 설계해야 합니다.

왜 위기가 오기 전에 이 역량을 마련해야 할까?

분쟁이 인증서 체인에까지 미치면 당사자 이외의 수많은 사람도 영향을 받을 수 있습니다. 고객은 그 다툼을 선택하지 않았지만 연결 장애의 비용을 부담할 수 있습니다. 장애가 발생한 뒤 급히 승계 절차를 마련하는 것으로는 이런 불확실성에서 고객을 보호하기에 이미 늦습니다.

루헝은 연속성과 떠날 권리를 미리 확보하고, 행정적 분쟁이 정상 작동하는 네트워크를 공격하는 무기가 되지 않게 하자고 주장합니다. 전체 논지는 노트 70: 문지기가 아니라 원장을 보호하라에서 읽을 수 있습니다.