요약

  • RFC 8360은 지원하는 리라잉 파티가 검증된 자원 집합(Verified Resource Set)을 계산해 과다청구(overclaim)하는 CA 인증서를 통과할 수 있게 하지만, 새로운 v2 정책 및 확장 OID를 사용하는 경우에 한한다. 구 프로파일을 사용하는 인증서는 기존의 거부 규칙을 그대로 유지한다.
  • 이 알고리즘은 보유하지 않은 자원을 절대 검증하지 않는다. ROA와 라우터 인증서는 청구된 모든 프리픽스 또는 ASN이 검증된 교집합 안에 들어맞을 때만 성공하며, 이 사양은 여러 트러스트 앵커 아래의 경합 청구 문제를 다루지 않는다.

반경이 매우 큰 작은 오류

RPKI 자원 인증서는 공개 키를 IP 주소 블록과 자율 시스템 번호에 결합한다. 권한은 계층적이다. 하위가 유효하게 보유할 수 있는 자원은 발급자가 유효하게 보유한 자원에 의존하며, 그 의존 관계는 구성된 트러스트 앵커까지 이어진다. RFC 3779가 자원 확장을 제공했고, RFC 6487이 RPKI에서 사용되는 인증서 프로파일과 검증 절차를 정의했다.

그 원래 절차에는 용서가 없는 성질이 있었다. CA 인증서가 발급자의 유효 보유 자원 밖의 자원을 단 하나라도 청구하면 인증서는 실패했다. 그에 의존하는 모든 것도 함께 실패했다. 큰 계층 구조의 상단 가까이에서 불일치가 생기면, 여전히 정상적으로 위임된 자원에 대한 객체들까지 포함해 하위 트리 전체가 사용 불가능해질 수 있었다.

불일치가 악의적일 필요는 없었다. RFC 8360은 과다청구로 이어지는 평범한 경로를 기술한다. 자원이 이전될 수 있고, 하위가 대체 인증서를 요청하기 전에 상위가 하위의 할당을 축소할 수 있으며, 관리 시스템과 데이터베이스가 서로 어긋날 수도 있다. 이 문서는 2018년의 RPKI에서 그런 사건은 드물 것으로 판단하면서도 그 영향이 클 수 있음을 강조했다. 중요한 설계 질문은 하나의 무효 청구가 무관한 유효 청구까지 오염시켜야 하는지였다.

Tim Bruijnzeels는 RFC 8360에 Geoff Huston, George Michaelson, Carlos Martinez, Andrew Newton, Donald Shaw와 함께 이름을 올렸다. 그 공동 저자들이 내놓은 답은 검증된 자원 집합(VRS)을 중심으로 한 대체 검증 알고리즘이었다. 인증서에 적힌 자원을 리라잉 파티가 실제로 사용할 수 있는 자원과 동일시하는 대신, 검증기는 인증 경로에서 살아남은 교집합만을 전달한다.

교집합이 곧 권한이다

RFC 8360은 IP 자원과 AS 자원을 따로 계산한다. VRS-IP는 경로를 따라 유효한 IP 자원들의 교집합이고, VRS-AS는 AS 번호에 대해 같은 역할을 한다. 과다청구가 없으면 결과는 RFC 6487과 동일하다. 동작상의 차이는 인증서의 청구 집합이 검증된 발급자 경로가 지지하는 범위를 벗어날 때만 나타난다.

이 대체 동작은 의도적으로 신호를 통해 구분된다. RFC 8360은 버전 2 인증서 정책 OID와 새 자원 확장 OID를 도입했다. 인증서가 그 프로파일을 사용하고 청구 자원이 VRS와 다르면, 지원하는 리라잉 파티는 과다청구된 자원을 보고하고 검증된 교집합으로 진행한다. 인증서가 구 RFC 6487 정책을 사용한다면 인증서는 여전히 거부되어야 한다. 따라서 새로운 의미론은 구 인증서에 보이지 않게 적용되는 완화가 아니다.

이 구분은 RFC를 가장 유혹적으로 잘못 읽는 방식을 막는다. 과다청구가 수용되는 것이 아니다. 지지되지 않는 부분이 사용 가능한 자원 집합에서 제거된다. CA 인증서는 여전히 무언가를 보유할 수 있기 때문에 검증된 트리에 남아 있을 수 있지만, 권한을 만들어낼 수는 없다. 빈 VRS조차도 임시 예외를 부여하지 않는다. CA 인증서는 그 상태가 일시적일 수 있으므로 즉시 거부할 필요는 없지만, 그 빈 집합 안에 속하는 자원이 없다면 어떤 하위 자원 청구도 검증될 수 없다.

사양이 사용하는 예를 보자. 하위 CA가 경로가 지지하는 192.0.2.0/24와 지지하지 않는 198.51.100.0/24를 함께 청구한다. VRS는 첫 번째 블록을 유지하고 두 번째를 제외한다. 첫 번째 블록에 대한 경로 시작점 권한(ROA)은 유효할 수 있지만 두 번째 블록에 대한 것은 유효할 수 없다. 하위 CA는 여전히 보이지만, 추가 프리픽스는 검증 경계를 넘지 못한다.

포함 관계는 서명 객체에서 계속된다

인증서 알고리즘은 첫 번째 관문일 뿐이다. RFC 6482는 ROA를 엔드 엔티티 서명 객체로 정의하며, 그 프리픽스와 최대 길이는 어느 시작 AS가 이를 광고할 수 있는지를 표현한다. RFC 8360에서 ROA의 모든 프리픽스는 엔드 엔티티 인증서의 VRS-IP 안에 들어맞아야 한다. 따라서 하나의 무단 프리픽스가 그 ROA를 무효화할 수 있으며, 발급 CA 인증서가 자신의 과다청구를 넘어 생존하더라도 마찬가지다.

RFC는 이 세분성에서 운영 교훈을 뽑는다. 보유자는 서로 다른 프리픽스에 대해 별도의 ROA를 발급할 수 있다. 무관한 프리픽스를 묶으면 공유된 실패 영역이 생기고, 분리하면 하나의 잃어버린 자원이 유효한 권한 부여들을 함께 끌어내리는 일을 막을 수 있다. 같은 논리가 BGPsec 라우터 인증서에도 적용된다. 청구된 모든 ASN은 VRS-AS에 포함되어야 하며, ASN별로 라우터 인증서를 나눠 발급하면 연쇄 실패를 제한할 수 있다.

대체 알고리즘은 또한 하나의 트러스트 앵커 경계에서 멈춘다. 서로 다른 트러스트 앵커가 겹치는 청구를 할 때 무엇을 해야 하는지는 정하지 않는다. 그것은 별개의 정책 문제다. 리라잉 파티의 로컬 기본 설정을 암호학적 권리와 동일시하지도 않는다. RFC 8360은 인증서 경로의 실패 포함 방식을 바꾸는 것이지, 검증된 위임이 사용 가능한 권한을 한정한다는 근본 규칙을 바꾸지 않는다.

이전(migration)은 메커니즘의 일부다

새 OID는 호환성 경계를 만든다. 대체 프로파일을 이해하지 못하는 리라잉 파티 구현은 그 OID를 지닌 인증서를 거부한다. 따라서 RFC 8360은 CA 채택보다 검증기 지원을 먼저 요구한다. 발급 측이 새 종류의 인증서를 발급할 수 있다는 이유만으로 새 의미론이 존재한다고 안전하게 판단할 수는 없으며, 소비 측이 먼저 그 종류를 인식해야 한다.

이전이 동시에 이루어질 필요는 없다. 문서는 인증서 단위로 프로파일의 선택적 사용을 허용한다. 루트 인증서는 구 정책 아래 두면서 하위 CA가 새 프로파일을 채택할 수 있으며, 리라잉 파티가 대체 알고리즘을 구현했다는 전제가 필요하다. 이를 통해 운영자는 계층 전체를 하나의 스위치로 전환하도록 강요받지 않고, 운영 리스크가 요구하는 지점에 포함 경계를 둘 수 있다.

RFC 8488은 역사적인 구현 관점을 제공한다. 2018년 RIPE NCC 검증기에 대한 설명에는 운영자가 선택하는 strict 모드가 있었고, 그 모드 밖에서는 대체 경로 동작이 구성 옵션으로 사용되었다. 이는 당시 한 검증기가 이 전환을 어떻게 노출했는지 보여주는 증거일 뿐, 현재 제품 기본값에 대한 진술도 RFC 8360의 인증서별 신호 규칙을 대신하는 것도 아니다.

이 남는 기여는 결함, 권한, 가용성의 정밀한 분리다. 인증서에 결함이 있을 수 있다. 결함은 보고되어야 한다. 무단 자원은 사용 불가능한 상태로 남아야 한다. 그러나 같은 지점 아래의 유효한 자원이 자동으로 사라져야 하는 것은 아니다. Bruijnzeels와 공동 저자들은 신뢰의 사슬을 약화시킨 것이 아니라, 그 폭발 반경을 더 작게 만든 것이다.

출처