요약

  • RFC 2401은 순서가 정해진 보안 정책 데이터베이스(Security Policy Database)와 보안 연계 데이터베이스(Security Association Database)를 분리했습니다. 전자는 트래픽을 폐기, 우회 또는 보호 대상으로 할지 결정했고, 후자는 활성 단방향 연계의 매개변수를 보유했습니다.
  • 규칙도 연계도 그 자체로 패킷에 대한 영수증이 아니었습니다. 아웃바운드 트래픽은 명시된 AH 또는 ESP 처리를 받아야 했고, 인바운드 트래픽은 암호 처리를 통과한 뒤 실제 사용된 연계가 적용 가능한 정책과 일치하는지 추가 검증을 거쳐야 했습니다.

사건이 끝난 뒤 두 가지 증거가 제출되는 상상을 해봅시다. 하나는 보호를 요구하는 규칙의 스크린샷이고, 다른 하나는 활성 암호 연계에 대한 데이터베이스 행입니다. 두 개를 함께 놓으면 설득력 있어 보입니다. 그러나 어느 쪽도 해당 패킷이 그 규칙에 일치했는지, 그 연계를 통과했는지, 요구된 변환을 받았는지, 상대에게 도달했는지, 애플리케이션에 의해 수용되었는지는 보여주지 않습니다.

1998년 11월에 발표된 RFC 2401은 인터넷 프로토콜을 위한 최초의 통합 보안 아키텍처로서, 이러한 주장들을 분리해 두는 언어를 제공했습니다. 이 문서는 IPv4와 IPv6에 대해 IP 계층의 접근 제어, 무결성, 출발지 인증, 재전송(안티 리플레이) 보호, 기밀성, 그리고 제한된 트래픽 흐름 기밀성을 기술했습니다. 그러나 이 모든 것을 하나의 약속으로 압축하지는 않았습니다. AH, ESP, 모드, 알고리즘, 키 관리 절차는 요구되는 서비스에 따라 다르게 조합될 수 있었습니다.

정책 계층에는 보안 정책 데이터베이스(SPD)가 있었습니다. 그 적용 범위는 사실상 전면적이었습니다. IPsec을 사용하지 않을 트래픽을 포함해 모든 인바운드·아웃바운드 IP 트래픽에 처분(disposition)이 주어져야 했습니다. 항목들은 순서를 가지며 주소와 상위 계층 필드로 트래픽을 선택했습니다. 일치 결과는 패킷 폐기, IPsec 우회, 또는 IPsec 보호 요구가 될 수 있었습니다. 보호 항목은 필요한 프로토콜 또는 번들, 모드, 알고리즘, 중첩 구조까지 명시했습니다.

순서가 있었기 때문에 정책은 단순한 서술이 아니라 실행 가능한 것이었습니다. 넓은 항목이 좁은 항목보다 앞에 놓이면, 좁은 항목이 고려되기 전에 패킷이 결정될 수 있었습니다. 따라서 정책은 승인된 문장들의 모음이 아니라, 선택자 일치와 위치가 결과에 영향을 미치는 하나의 수열이었습니다. 방향도 중요했습니다. 아웃바운드 결정의 필드와 요구되는 처리는 인바운드 검사의 단순한 거울상이 아니었습니다.

SPD 옆에는 보안 연계 데이터베이스(SAD)가 있었습니다. 각 보안 연계(SA)는 단방향(simplex)이어서 한 방향의 트래픽만 보호했습니다. 따라서 일반적인 양방향 보호에는 두 개의 연계가 필요했습니다. SA는 보안 매개변수 색인(SPI), 목적지 주소, 그리고 AH 또는 ESP의 선택으로 식별되었습니다. 데이터베이스 항목에는 시퀀스·안티 리플레이 상태, 알고리즘과 키, 수명(lifetime), 모드, 경로 MTU 정보가 저장될 수 있었습니다.

이는 운영에 필수적인 상태였지만, 서로 다른 질문에 답하는 것이었습니다. SAD 항목의 존재는 특정 매개변수를 가진 연계가 이용 가능하다는 사실만 보여줍니다. 어떤 패킷이 그 항목을 선택했는지, 실제로 어떤 패킷이 사용했는지는 보여주지 않습니다. 상대의 수신, 애플리케이션의 승인, 서비스 결과를 증명하지도 않습니다. 이 아키텍처 직전에 발표된 RFC 2367의 PF_KEY 인터페이스는 이러한 상태의 관리를 애플리케이션에 보이게 만들었고, RFC 2401은 그 상태를 더 큰 패킷 처리 계약 안에 배치했습니다.

아웃바운드 패킷의 경우 결합이 순서대로 일어나야 했습니다. 구현은 패킷을 SPD와 대조합니다. 폐기면 경로가 끝납니다. 우회면 IPsec 없이 일반 전송이 허용됩니다. 보호 규칙은 적합한 기존 연계를 선택하거나 필요한 SA 또는 번들의 생성을 시작합니다. 그 이후에야 명시된 AH 또는 ESP 작업이 요구된 순서대로 적용되고, 전달 또는 전송이 이루어질 수 있습니다. 저장된 의도와 활성 연계는 그것이 발생시키려 한 변환의 상류에 머물러 있었습니다.

인바운드 경로에는 간과하기 쉬운 두 번째 경계가 있었습니다. 목적지 주소, 보안 프로토콜, SPI가 SA를 선택합니다. 그 다음 AH 또는 ESP 처리가 무결성이나 출발지를 검증하고, 재전송을 거부하며, 선택된 서비스가 기밀성을 제공하는 경우 복호화할 수 있습니다. 그 단계에서의 성공은 아직 완전한 승인 결정이 아니었습니다.

IPsec 헤더가 처리된 뒤, 결과 패킷은 인바운드 SPD 항목과 일치해야 했습니다. 구현은 실제 사용된 연계—그 순서를 포함해—가 해당 정책을 충족하는지 확인해야 했습니다. 후보 항목이 비교에 실패하면 다른 적용 가능한 항목들을 검토해야 했습니다. 정책 검사가 성공한 이후에만 패킷이 전송 계층으로 넘어가거나 포워딩될 수 있었습니다. SA 하에서의 암호학적 유효성과 지배하는 정책 하에서의 승인은 의도적으로 분리된 영수증이었습니다.

AH와 ESP도 편리한 축약 표현에 저항했습니다. 1998년 인증 헤더(AH)는 무결성과 데이터 출발지 인증, 선택적 안티 리플레이 서비스를 제공했지만 기밀성은 제공하지 않았습니다. ESP는 기밀성을 제공하고 인증과 무결성을 선택적으로 제공할 수 있었지만, 커버리지 경계가 달랐습니다. "IPsec이 암호화했다"는 보편적 서술이 아니었고, 우회(bypass)는 명시적으로 아무런 IPsec 보호도 없음을 뜻했습니다.

RFC 2401은 자신의 아키텍처가 주변의 모든 것을 보완할 수 있다고 주장하지 않았습니다. 전체 보안은 여전히 구현 품질, 운영체제 보호, 난수 발생원, 관리에 의존했습니다. 또한 이 문서는 현재의 운영 지침이 아닙니다. RFC 3168은 이후 명시적 혼잡 통지(Explicit Congestion Notification)의 처리 방식을 갱신했고, RFC 4301이 2005년 아키텍처를 대체하며 정책 데이터베이스, 선택자, 단편 처리, 상대 승인을 정교화했습니다.

남는 역사적 교훈은 더 좁습니다. 정책 의도, 설치된 연계 상태, 패킷 실행은 서로 다른 증거 계층에 놓여 있습니다. Lu Heng의 표현으로 말하면, 상징적 주장은 실행 중인 시스템과 현지 검증을 통해서만 운영적 힘을 얻습니다. 이는 분석적 렌즈이지 RFC가 사용한 언어가 아닙니다. 신중하게 적용하면 11단계의 보관(custody) 연쇄가 나옵니다. 출처와 버전, 적재된 규칙, 순서화된 일치, 요구된 보호, 현재 연계, 실제 변환 또는 검증, 인바운드 정책 비교, 네트워크 또는 전송 경계로의 전달, 상대의 수신, 애플리케이션 처리, 그리고 최종적으로 서비스 결과입니다. 앞 단계는 정직하게는 뒷 단계를 대신할 수 없습니다.

출처