요약

  • RFC 2411은 원래 IPsec 문서 모음을 일곱 가지 책임 그룹으로 나누어, 아키텍처, ESP, AH, 알고리즘, 할당된 값, 키 관리가 서로의 규칙을 계속 복사하지 않도록 했다.
  • 이 로드맵은 사양의 확장을 쉽게 만들었지만 Informational 문서였기 때문에, 어떤 개정판을 구현체가 따랐는지, 두 피어가 어떤 알고리즘을 협상했는지, 키가 커널에 도달했는지, 보호된 트래픽이 실제로 동작했는지는 증명할 수 없었다.

RFC 2411에서 가장 영향력이 큰 도표에는 패킷이 하나도 없다.

맨 위에는 아키텍처 상자가 놓여 있다. 그 아래에 ESP와 AH가 자리한다. 알고리즘 문서들은 양옆으로 부채꼴처럼 퍼져 나간다. 해석 영역(Domain of Interpretation)은 가운데를 차지하며, 할당된 값들이 각 조각들이 서로를 이름으로 부를 수 있게 해 준다. 키 관리는 아래에서 들어온다. 화살표들은 기계실의 배관처럼 페이지를 가로지른다.

이를 ‘문서에 대한 문서’—실제 공학이 끝난 뒤에 만들어진 정리용 안내서—로 읽고 싶은 유혹이 있다. 그러나 정반대가 진실에 더 가깝다. 1998년 11월 무렵, IPsec은 이미 여러 사양의 집합이 되어 있었고, 그 내부 경계가 미래의 확장이 여전히 이해 가능한지를 결정할 수 있었다. ESP를 다시 서술하는 암호 문서, 자기만의 키 길이를 발명하는 키 관리 초안, 또는 같은 규칙을 서로 다르게 복사하는 두 인증 문서는 패킷 도표 하나 바꾸지 않고도 상호운용성을 깨뜨릴 수 있었다.

RFC 2411은 그 실패가 일어나기 전에 막으려 했다. 그 주제는 단순히 논문을 어디에 보관할지가 아니었다. 그 주제는 규칙이 어디에서 권위를 얻어야 하는가였다.

저자들은 위험의 하나를 ‘초안 폭발(draft explosion)’ 효과라고 불렀다. 기본 IPsec 문서들이 RFC가 된 뒤에도 새로운 암호화·인증 알고리즘은 계속 등장할 것이었다. 알고리즘마다 아키텍처나 패킷 형식 사양을 다시 열면 공통 계층이 불안정해진다. 모든 알고리즘 초안에 공통 계층을 반복하면 같은 시스템에 대한 중복되고 결국 서로 모순되는 서술이 만들어진다. 로드맵은 세 번째 길을 제시했다. 공유되는 동작은 공유 문서에 두고, 새 알고리즘 문서는 정말로 새로운 결합만 서술하게 하라.

이것은 편집 아키텍처로 실천되는 최소 사양이다.

아키텍처 문서는 일반 개념, 보안 요구 사항, IPsec 시스템의 형태를 담당했다. ESP와 AH 문서는 각자의 패킷 형식과 일반 처리를 담당했다. 암호화 알고리즘 문서는 특정 암호가 ESP에 어떻게 들어맞는지 설명했다. 인증 알고리즘 문서는 같은 동작이 ESP와 AH 모두에 적용될 때 그 메커니즘을 한 번만 서술했다. DOI는 공통 이름과 협상 가능한 값을 공급했다. 키 관리 문서는 키 재료의 설정과 취급을 담당했다.

이 분리는 잘 동작한 뒤에야 당연하게 들린다.

키 길이를 생각해 보자. 키 관리 프로토콜은 선택된 알고리즘이 무엇을 요구하는지 모르면 적절한 양의 재료를 만들어 낼 수 없다. 그러나 모든 알고리즘의 키 길이, 약한 키 취급, 패리티 규칙, 정렬 규칙을 키 관리에 넣으면 그 프로토콜이 자신이 소유하지 않은 암호학 세부사항의 목록이 되어 버린다. RFC 2411은 그런 속성들을 알고리즘 문서에 배정했다. 키 관리는 충분한 크기와 강도의 재료를 만들어 내면 되었다. 아키텍처는 ESP가 기밀성과 인증을 결합할 때 여러 키를 어떻게 추출할 수 있는지 설명했다.

그리고 로드맵은 거기서 멈췄다.

구현체가 재료 블록 전체를 커널에 넘겨 ‘쪼개고 나누는’ 작업을 커널이 하게 할지, 아니면 키 관리 프로세스에서 먼저 키를 나눌지는 구현 문제였다. 회선 동작과 암호학적 결과는 일치해야 했다. 내부 경계는 그럴 필요가 없었다.

이 문장에는 간결한 설계 윤리가 담겨 있다. 서로 독립적인 시스템들이 반드시 공유해야 하는 것만 표준화하라. 문서에 쓸 공간이 있다는 이유만으로 내부 선택을 중앙화하지 말라.

선택 사양도 같은 취급을 받았다. 알고리즘 설계자들은 기술적으로 타당한 공통 값이 있으면 선택 매개변수를 고정하라는 요청을 받았다. 런타임에 협상되는 매개변수가 늘어날수록 실패 표면도 커진다. 제안 조합은 더 많아지고, 코드 경로는 더 늘어나고, 서로 규격을 준수하는 두 제품이 사용 가능한 공통 선택을 하나도 갖지 않을 가능성도 커진다. 고정된 값은 그 비용을 줄일 수 있었다.

그러나 로드맵은 균일함을 그 자체를 위해 요구하지 않았다. 옵션이 열려 있어야 한다면 그 문서는 이유를 밝히고, 관련 기본값이나 범위를 서술하며, 형식과 처리에 미치는 영향을 설명해야 했다. 선택 동작도 여전히 경계가 필요했다. ‘설정 가능(configurable)’은 사양의 대체물이 아니었다.

권장 내용 목록은 놀랄 만큼 운영적이었다. 알고리즘 문서는 최소·최대·권장 키 크기, 약한 키, 난수 생성, 갱신 주기, 성능, 블록 및 필드 형식, 패딩, 다른 알고리즘과의 상호작용, 알려진 공격, 구현 함정, 검증 방법, 테스트 벡터를 논의해야 했다. RFC 2411은 그런 테스트를 수행하지 않았다. 다만 메커니즘에 가장 가까운 문서들이 증거를 가능하게 만들 것을 요구했다.

그렇기 때문에 이 로드맵을 증거 자체와 혼동해서는 안 된다.

RFC 2411은 Informational이었다. 상태 고지는 이 문서가 인터넷 표준을 명시하는 것이 아니라고 말했다. 보안 섹션은 실제 보안 절차를 위해 독자를 아키텍처·프로토콜·알고리즘 문서로 되돌려 보냈다. 인증 없이는 많은 암호화 알고리즘이 안전하지 않다는 경고조차, 배포된 시스템이 그렇게 했다는 증명서가 아니라 올바른 출처를 모으라는 방향 지시였다.

로드맵 항목은 어떤 알고리즘 문서가 존재한다는 것을 보여 줄 수 있다. 특정 빌드가 그 문서를 구현했다는 것은 보여 줄 수 없다. 제품 선언은 지원 주장을 보여 줄 수 있다. 두 피어가 무엇을 선택했는지는 보여 줄 수 없다. 협상 로그는 선택된 제안을 보여 줄 수 있다. 양쪽 단말이 결과 SA를 설치했는지는 보여 줄 수 없다. 설치된 SA는 로컬 상태를 보여 준다. 유용한 패킷이 네트워크를 건너 애플리케이션에 도달했는지는 보여 줄 수 없다.

이 구분은 문서들이 서로 다른 속도로 바뀔 때 가장 중요해진다.

암호학적 판단이 바뀌는 동안에도 패킷 형식은 안정적으로 남을 수 있다. 등록된 식별자는 알고리즘이 현명하지 않게 된 뒤에도 남아 있을 수 있다. 구현체는 호환성을 위해 오래된 변환을 계속 들고 다닐 수 있다. 운영자는 그것을 비활성화할 수 있다. 두 피어는 다른 무엇을 협상할 수 있다. 로드맵은 그런 질문들을 잘 찾아 준다. 그러나 자기 페이지만으로 그 전부에 답할 수는 없다.

이후의 역사는 그 한계를 명시적으로 만들었다. RFC 6071은 2011년, IPsec과 IKE 문서 모음이 원래 워킹 그룹, 그 후속 그룹들, 그리고 IPsec을 사용하는 다른 그룹들로 번져 나간 뒤에 RFC 2411을 폐기했다. 대체 문서는 자신을 스냅샷이라 불렀다. 2011년 2월 기준의 범주와 요구 수준을 나열하면서, 이후의 RFC가 이를 바꿀 수 있다고 경고했고, 로드맵이 충돌하면 다른 RFC가 우선한다고 밝혔다.

지도는 스스로의 종속성을 선언했다.

RFC 6071은 동시에 두 가지 현실을 기록했다. 새 IPsec 사양들이 옛 세트를 폐기했음에도 구버전은 운영에서 여전히 흔했다. IKEv2가 IKEv1을 대체했음에도 IKEv1은 배포된 시스템에 남아 있었다. 형식적 승계가 설치된 코드를 지우지 않았다. 반대로 설치된 코드가 문서가 폐기되는 것을 막지도 않았다. 표준 상태와 운영 인구는 서로 다른 사실이었다.

지도의 형태도 진화했다. 결합 모드 알고리즘이 자기 자리를 얻었다. 필수 알고리즘 요구는 독립적인 안내 문서로 옮겨졌다. IKEv2는 IKEv1이 여러, 때로는 서로 모순되는, 문서에 흩뿌린 재료를 통합했다. 원래의 모듈화는 확장을 가능하게 했지만, 쌓인 모듈들은 발견 문제를 만들기도 했다. 좋은 경계도 늙는다. 그것들은 변화를 관리하기 가장 싼 자리에 대한 가설로 남는다.

현대의 알고리즘 안내는 이 중심 통찰을 보존한다. RFC 8221은 자주 바뀌는 암호학 구현 요구를 더 안정적인 ESP·AH 패킷 사양에서 분리한다. 더 강한 알고리즘이 등장하고, 오래된 것은 약해지며, 하드웨어는 대형 게이트웨이부터 제약된 기기까지 분포한다는 점을 설명한다. 내일의 필수 구현 알고리즘은 요구가 바뀌기 전에 이미 널리 이용 가능해야 한다.

그러나 그 신중한 단계화는 등록된 모든 알고리즘이 권장된다는 말이 아니다. IANA 번호는 값을 모호하지 않게 만든다. 그것으로 알고리즘이 최신이거나, 안전하거나, 활성화되었거나, 선택되었다는 뜻은 되지 않는다. RFC 9395는 이후 IKEv1과, 오래된 레지스트리와 문서가 여전히 서술하던 폐기된 알고리즘들을 폐지했다. 역사 기록은 남았고, 운영 안내는 옮겨 갔다.

따라서 RFC 2411은 IPsec 논문 목록보다 더 깊은 이유로 인터넷의 역사에 자리한다. 스택 전체를 하나의 문서가 통치하게 만들지 않으면서 합의를 확장하는 방법을 포착했기 때문이다.

공유 규칙은 모든 구현체가 필요로 하는 가장 작은 계층에 두라. 전문 규칙은 그것이 구속하는 메커니즘 옆에 두라. 협상 가능한 값에는 안정적인 이름을 주라. 상호운용성에 이롭다면 옵션을 고정하라. 열어 두려면 반드시 설명과 함께 두라. 네트워크가 볼 필요가 없는 내부 설계는 로컬에 남겨 두라. 그리고 어디에 증거가 속하는지 알려 주는 문서와, 구동 중인 시스템이 만든 증거를 절대 혼동하지 말라.

로드맵은 모든 규칙을 제자리에 놓았다. 그러나 각 규칙을 실제 서비스에 투입한 것은 구동 중인 코드였다.

출처