요약

  • RFC 3948은 IKE 제어 메시지와 UDP 캡슐화된 ESP 패킷을 하나의 NAT 매핑에 함께 두었으며, 유효한 ESP SPI가 0이 될 수 없다는 점을 이용해 네 개의 0 옥텟으로 IKE를 표시했습니다.
  • 이 표식은 파서를 선택했을 뿐입니다. SA 조회, 안티 리플레이, 암호학적 검증, 내부 주소 정책, 애플리케이션 전달은 여전히 별개의 판단으로 남았고, 1옥텟짜리 NAT keepalive는 피어 생존 확인이 아니었습니다.

미들박스를 가로지르는 하나의 구멍

2005년 무렵 IPsec은 주변 네트워크와의 실질적인 충돌에 직면해 있었습니다. ESP는 페이로드를 보호했지만, 배포된 많은 주소 변환기는 전송 계층 포트를 통해 흐름을 인식했습니다. 네이티브 ESP는 이러한 장비들이 일반적으로 의존하는 TCP 또는 UDP 모양을 제공하지 않았습니다. ESP를 UDP로 전달하면 변환기에게 익숙한 외부 흐름을 주었지만, 이제 IKE 협상과 ESP 데이터가 동일한 변환 경로를 통해 동일한 엔드포인트에 도달해야 하는 새로운 문제가 생겼습니다.

RFC 3948은 포트를 공유하기로 했습니다. 그 이유는 구체적이었습니다. 하나의 매핑이 별개의 매핑들보다 확장성이 좋았고, 그 매핑 위의 일반 트래픽이 별도의 IKE keepalive 필요성을 줄였으며, 방화벽은 하나의 포트 규칙만 필요했고, 구현체는 하나의 외부 경로만 관리하면 되었습니다. 그와 짝을 이루는RFC 3947은 NAT 통과 IKE 교환을 UDP 4500으로 옮기고 그 선택을 둘러싼 협상 절차를 제공했습니다.

공유가 프로토콜을 합쳐 놓은 것은 아니었습니다. 도착한 UDP 페이로드는 여전히 키와 연관을 관리하는 IKE 또는 보호된 트래픽을 전달하는 ESP 중 한쪽으로 가야 했습니다. 더 이상 포트 번호가 그 선택을 할 수 없었습니다. 그래서 RFC 3948은 페이로드의 처음 32비트를 작은 분류 네임스페이스로 만들었습니다.

0이 말할 수 있도록 0을 예약했다

ESP 헤더는 32비트 Security Parameters Index로 시작합니다. SPI는 수신자가 패킷을 처리해야 하는 Security Association을 찾도록 돕습니다. RFC 3948이 사용한 ESP 정의인RFC 2406은 0을 로컬 및 구현별 용도로 예약하고 일반적인 와이어 트래픽에서 배제합니다. RFC 3948은 이를 운영 규칙으로 명시했습니다. 이 경로의 ESP SPI는 0이 아니어야 합니다.

4500 포트의 IKE 트래픽은 그 반대의 모양을 받았습니다. 값이 0인 네 개의 옥텟, 즉 Non-ESP Marker가 UDP 뒤이자 IKE 헤더 앞에 놓였습니다. 이 옥텟들은 ESP SPI가 있었을 정확한 위치를 차지했습니다. 수신자는 한 단어만 검사하면 됐습니다. 0이면 IKE 처리로, 0이 아니면 ESP 처리로 향했습니다.

이것은 우아했습니다. 별도의 협상된 포트나 더 큰 봉투를 추가하는 대신 불가능한 값을 재사용했기 때문입니다. 그러나 그 범위는 좁았습니다. 이 표식은 어느 피어가 메시지를 보냈는지 말해주지 않았습니다. IKE Security Association을 식별하지도, 헤더에 서명하지도, 교환을 승인하지도, 뒤따르는 바이트가 형식에 맞는지 증명하지도 않았습니다. 두 문장 위의 표지판이었지, 어느 문 뒤의 경비원이 아니었습니다.

같은 한계가 ESP 쪽에도 적용됐습니다. 0이 아닌 첫 단어는 SPI로 취급될 수 있지만 자동으로 유효한 SPI는 아니었습니다. 수신자는 여전히 그 SPI와 목적지 문맥에 맞는 설치된 연관을 필요로 했습니다. 시퀀스 번호, 안티 리플레이 상태, 암호학적 보호, 트래픽 정책 처리도 여전히 필요했습니다. 알 수 없는 SPI, 리플레이 실패, 무결성 실패, 금지된 내부 트래픽은 모두 첫 분류가 완벽하게 작동한 후에도 패킷을 끝낼 수 있었습니다.

세 번째 메시지는 대화가 아니라 매핑을 유지했다

공유 매핑은 놀랍도록 작은 유지보수 패킷도 함께 운반했습니다. 값이0xFF인 한 옥텟입니다. RFC 3948은 이것을 NAT keepalive라고 불렀습니다. 발신자는 유휴 구간 후에 이를 내보내 변환기가 UDP 매핑을 잊지 않도록 할 수 있었습니다. 수신자는 이를 무시하도록 권고받았습니다.

사양은 특히 유용한 부정적 경계를 그었습니다. NAT keepalive의 수신은 연결이 살아 있는지 판단하는 데 사용되어서는 안 됩니다. 미들박스는 데이터그램이 지나갔기 때문에 타이머를 갱신할 수 있습니다. 그것은 IKE 상태 머신, 설치된 ESP 연관, 성공한 복호화, 허용된 내부 트래픽 또는 작동하는 애플리케이션에 대해 아무것도 말하지 않습니다. 피어 애플리케이션이 그 옥텟을 소비할 필요조차 없습니다.

발표 당시의 기본값들, 즉 필요한 keepalive 전의 20초 아웃바운드 침묵과 연관이 존재한 후 최대 5분은 구성 가능한 동작을 묘사한 것이지 영원한 측정치가 아니었습니다. 더 중요한 것은 타이머 소유자가 달랐다는 점입니다. 변환기가 매핑 만료를 통제했고, 엔드포인트가 keepalive 전송을 통제했으며, IKE와 ESP가 각자의 연관 수명을 통제했습니다. 어느 하나의 틱도 나머지를 증명하지 못했습니다.

올바른 분류는 더 어려운 정책을 뒤에 남겼다

UDP 캡슐화는 ESP를 대체하지 않았습니다. RFC 3948은 UDP 헤더를 삽입하거나 제거한 뒤 일반적인 ESP 처리를 요구했습니다. 역캡슐화 후에도 구현체는 NAT가 만든 주소 효과를 여전히 다뤄야 했습니다.

터널 모드에서 로컬 정책은 내부 발신 주소를 허용 범위와 비교 검증하거나, 피어에 할당된 주소와 비교하거나, 로컬 네트워크를 위해 변환할 수 있었습니다. 전송 모드에서는 변경된 IP 주소가 내부 TCP 또는 UDP 체크섬을 망가뜨릴 수 있었고, 수신자는 IKE에서 얻은 원 주소 정보로 이를 조정하거나, 재계산하거나, RFC가 기술한 좁게 제한된 무결성 보호 경로를 취할 수 있었습니다. 네 바이트 검사를 통과하는 것은 이 어느 질문도 결정하지 않았습니다.

보안 섹션은 남은 모호성을 드러냈습니다. 서로 다른 변환기 뒤의 두 원격 노트북이 같은 사설 주소를 사용할 수 있었습니다. 그러면 게이트웨이는 같은 내부 목적지로 이어지는 것처럼 보이는 여러 연관을 보게 됩니다. 하나의 공용 주소 뒤의 여러 클라이언트가 겹치는 트래픽 설명을 제안할 수도 있어, 단순한 아웃바운드 필터는 올바른 연관을 선택할 수 없습니다. 외부 주소는 변환기까지만 전달을 조율했을 뿐, 그 뒤의 모든 호스트나 정책에 대한 고유한 이름이 되지는 못했습니다.

이것들은 NAT 통과를 거부할 이론적 이유가 아니었습니다. 배포된 장비와 최소한의 호환성 계층을 작동시키기 위한 대가였습니다. 이전의RFC 3715는 요구 사항과 충돌을 정리해 놓았습니다. RFC 3948은 와이어 메커니즘을 제공하면서 충돌을 해결할 책임은 구현체에 남긴 것이지, 래퍼가 그것을 없앤 것처럼 꾸미지 않았습니다.

작은 규칙은 작게 남았기 때문에 살아남았다

RFC Editor 기록은 RFC 3948을 2005년 1월에 발행된 Standards Track 문서로 확인합니다. 그승인된 오류 정정은 서론의 한 상호 참조를 수정할 뿐, 패킷 형식이나 네 개의 0 규칙은 바꾸지 않았습니다.

이후의 IKEv2도 이 배치를 유지했습니다.RFC 7296은 UDP 4500에서 보내는 IKE 메시지가 네 개의 선행 0 옥텟을 실으며, ESP 헤더는 UDP를 바로 따르고 유효하게 SPI 0으로 시작할 수 없다고 말합니다. 또한 개시자가 NAT의 존재를 먼저 증명하지 않고 4500을 사용할 수 있도록 허용합니다. 따라서 포트 선택만으로 변환된 경로의 증거로 소급 채워 넣을 수 없습니다.

RFC 3948의 지속 가능한 교훈은 네 바이트가 IPsec을 보호했다는 것이 아닙니다. 좋은 조율 규칙은 하나의 소박한 일을 정확하게 수행할 수 있다는 것입니다. 이 표식은 두 파서가 공존하게 만들었습니다. SPI는 후보 패킷을 수신자 쪽 상태에 연결했습니다. 암호학적 및 리플레이 처리가 그 상태를 검증했습니다. 로컬 정책이 내부 트래픽을 통제했습니다. 애플리케이션 증거가 결과를 확정했습니다. 이 영수증들을 하나로 뭉개면 판단이 실제로 일어난 지점을 지우는 대가로만 시스템이 더 단순해 보입니다.

출처