요약

  • RFC 8247의 알고리즘 요구사항은 IKEv2 구현체들 사이의 상호운용성 기준선을 만들 뿐, 특정 두 피어 쌍이 협상한 알고리즘을 식별해 주지는 않습니다.
  • 선택된 트랜스폼, 로컬 정책 결정, 인증된 IKE SA, Child SA, ESP 패킷, 서비스 결과는 각각 자체적인 시점 한정 근거를 필요로 합니다.

“구현 의무(mandatory to implement)”라는 표현은 역량에 관한 질문에 답하는 것입니다. 이는 상호운용 가능한 두 구현체가 나올 수 있도록 어떤 공통 알고리즘이 존재해야 하는지 설계자가 알도록 돕습니다. 그러나 인시던트 보고서가 보통 의미하는 운영상의 질문, 즉 “이 두 피어가 실제로 이 시점에 무엇을 사용했는가?”에는 답하지 않습니다.

RFC 8247은 문서 서두의 범위 규정에서 이 구분을 분명히 보여줍니다. IKE는 알고리즘을 포함한 IPsec 보안 연관(Security Association) 매개변수를 협상하지만, 피어들은 각자의 로컬 정책에 따라 서로 다른 알고리즘을 협상할 수 있습니다. 따라서 요구사항 표는 제안/선택 기록을 대체할 수 없습니다. 클라이언트가 알고리즘을 구현하면서도 어느 한 제안에서 이를 빼놓을 수 있고, 응답자가 이를 지원하면서도 다른 허용된 트랜스폼을 선택할 수 있으며, 정책이 구현 가능한 선택을 기각할 수도 있습니다. “MUST implement”는 제안도 아니고 수락도 아닙니다.

다음 경계는 연관 상태입니다. 포획된 제안과 선택 기록만으로 인증이 완료되고 IKE SA가 수립되었다는 것을 증명하지는 못합니다. 생성된 Child SA는 셀렉터, 키, 수명을 갖는 또 하나의 기록이며, 각각 고유한 식별자가 필요합니다. 암호 구성에 관한 주장은 표준 표를 대신 사용하지 말고, 피어 신원, 제안 순서, 선택된 트랜스폼, 인증 결과, SA 식별자, 타임스탬프, 실패 알림을 보존해야 합니다.

RFC 8247은 익숙한 과잉 확장도 차단합니다. 이 문서는 ESP 패킷 암호화에 사용되는 알고리즘을 갱신하지 않는다는 점을 명시합니다. 따라서 이 문서의 IKEv2 지침이 데이터 플레인 전체에 대한 포괄적 레이블이 될 수 없습니다. ESP가 패킷을 암호화했다고 말하려면 ESP와 SA 근거가, 어떤 피어가 패킷을 받았다고 말하려면 그 피어에서의 관측이, 서비스가 동작했다고 말하려면 애플리케이션 수준의 결과가 필요합니다. 실제 시스템에서 이러한 사실은 성공적인 협상에 뒤따를 수 있지만, 구현 요구사항 안에 담겨 있지는 않습니다.

시간 역시 의미를 바꿉니다. RFC 8247은 오늘 사용 중인 알고리즘이 내일 의무 구현 대상이 된다는 보장이 없다고 지적합니다. 날짜가 표시된 컴플라이언스 주장은 영구적인 재고 목록이 아닙니다. IANA의 IKEv2 레지스트리는 트랜스폼 이름과 번호를 식별할 뿐, 어떤 운영 중인 피어가 무엇을 구현하거나 협상했는지는 보여주지 않습니다.

Lu Heng의 Minimum Initial Specification과 Running-Code Primarity 원칙이 적절한 보고 규율을 제공합니다. 근거가 지지하는 가장 작은 사실만 기록하십시오. 어떤 문서가 구현을 요구한다, 어떤 빌드가 지원을 보고한다, 어떤 피어가 트랜스폼을 제안했다, 응답자가 그것을 선택했다, 인증이 특정 SA를 생성했다, ESP 카운터가 보호된 패킷을 관측했다 — 각각은 가치가 있습니다. 이를 사이의 연결 근거 없이 “그 VPN은 보안 알고리즘 X를 사용했다”로 합치면, 어떤 출처도 제공하지 않은 결론이 만들어집니다.

Wouters는 이 IETF 공동 표준의 네 명의 저자 중 한 명입니다. 그의 공개 IETF 프로필은 이러한 저자 귀속을 뒷받침하지만, 특정 벤더, 고객, 엔드포인트, 운영 중인 네트워크에 대한 권한은 아닙니다. 보존할 가치가 있는 기여는 표준 자체의 절제입니다. 상호운용성 지침은 구현체에 하한선을 설정할 뿐, 협상되고 관측된 보안은 별개의 장부에 기록됩니다.

출처