요약

  • RFC 3193은 ESP를 사용해 L2TP의 제어 및 데이터 트래픽을 보호하도록 요구했지만, IPsec 보안 연합은 그 선택자(selector)가 터널이 설정 과정에서 선택하는 주소와 포트를 따라가야만 유효했습니다.
  • 패킷 단위 검증은 PPP가 인증한 신원이 아니라 IKE의 신원을 상속했습니다. 여러 사용자가 쓰는 기기에서는 트래픽을 격리하기 위해 별도의 로컬 정책이 필요했습니다.

터널의 보안은 접속 아이콘이 나타나는 순간에 시작되지 않았습니다. RFC 3193에게 그 시작은 터널을 열려는 첫 메시지보다 앞섰습니다.

SCCRQ 메시지는 L2TP 제어 연결을 만듭니다. 이를 보호할 수 있는 IPsec 보안 연합이 존재하기 전에 메시지가 나가면, 창설 작업 자체가 그 작업이 만들려던 경계 밖에 놓였습니다. 그래서 초기 필터는 미리 설치되어 있어야 했습니다. SCCRQ의 전송이 IKE를 촉발할 수 있었고, SA가 수립되지 못하면 패킷은 폐기되어야 했습니다.

이 시간적 요구는 프로토콜 간 차이에서 비롯되었습니다. L2TP는 자기 소켓을 알고 동적인 출발지 포트를 고를 수 있었습니다. 응답자는 다른 포트에서 답할 수도 있었습니다. L2TP 사양은 심지어 다른 IP 주소를 선택하는 것까지 허용했습니다. 반면 IKE는 Quick Mode에서 주소, 프로토콜, 포트로 표현되는 트래픽 집합을 협상했습니다. 응용이 아직 결정하지 못한 데이터를 정확하게 보호할 수 없었습니다.

RFC 3193은 명시적인 협력을 도입했습니다. L2TP가 개시자의 포트를 알게 되면 그 포트를 IPsec 필터 데이터베이스에 주입했습니다. IKE는 협상을 마치고 구체적인 필터를 SA에 연결했습니다. 수립이 진행되는 동안 일부 규칙은 가능한 새 포트를 수용했고, 터널이 고정되면 잔여 보안 연합과 규칙은 제거될 수 있었습니다.

주소 변경은 암묵적인 연속이 아니었습니다. 응답자는 원래 보호 경로를 통해 "Try Another"와 새 주소를 담은 StopCCN을 보내야 했습니다. 개시자는 형식을 확인하고, 새 정책을 설치하고, 새로운 Phase 1과 Phase 2를 협상한 뒤에야 다른 SCCRQ를 보냈습니다. 운영 목적이 같더라도 새 주소에는 새로운 암호 관계가 필요했습니다.

포트 변경은 또 다른 경로를 거쳤습니다. SCCRP 이전에 결정되어야 했습니다. L2TP가 필터를 추가하고 응답자가 새로운 Phase 2를 개시했습니다. 포트를 발견하는 데 필요한 시간적 여유가 영구 허가로 이어지지는 않았습니다. 최종 필터는 실제로 협상에서 승리한 소켓을 기술해야 했습니다.

그래서 "UDP 1701을 쓴다"는 관찰은 불충분했습니다. 1701은 단지 최초의 만남 장소일 수 있었습니다. 터널의 신원은 주소, 최종적으로 선택된 포트, IPsec 보안 연합, L2TP 상태에도 자리했습니다. 포트 번호는 자격 증명이 아니었습니다.

패킷 수신에는 같은 규율이 유지되었습니다. L2TP는 먼저 IPsec이 그 패킷을 인증하거나 복호화했는지 확인해야 했습니다. 이를 통해 패킷이 평문으로 도착하지 않았고 기대한 SA에 속한다는 사실을 알 수 있었습니다. 그다음에는 주소와 포트를 그 터널을 만들 때 쓴 소켓과 비교해야 했습니다. 암호학적으로 신뢰할 수 있는 상대도 잘못된 L2TP 컨텍스트로 패킷을 보낼 수 있었습니다. 첫 번째 검사를 통과한다고 두 번째 검사가 사라지지 않았습니다.

단일 상태 기계도 없었습니다. L2TP 연결, IKE Phase 1, Phase 2 SA, 필터는 서로 다른 저장소에 살았습니다. 터널이 끝나면 그 터널을 위해 만들어진 SA는 제거되고 해당 알림이 전송되어야 했습니다. IKE가 삭제를 받으면 L2TP에 통보해야 했습니다. 필요한 확인이 끝난 뒤에야 상태와 관련 필터를 안전하게 철거할 수 있었습니다.

"VPN 연결 끊김" 로그 하나만으로는 이 복합적인 종료가 증명되지 않습니다. 터널은 사라졌는데 SA가 살아남을 수도 있고, SA는 삭제됐는데 응용이 여전히 활성 터널처럼 보이는 것을 붙잡고 있을 수도 있었습니다. RFC 3193은 두 세계를 조율했을 뿐, 그것들이 하나의 트랜잭션 행인 것처럼 꾸미지 않았습니다.

캡슐화는 링크의 물리적 현실도 바꿨습니다. PPP는 보통 1,500바이트로 동작했지만 L2TP와 IPsec이 헤더를 더했습니다. 문서는 그 오버헤드를 뺀 가용 MTU를 계산해 LCP 이전에 PPP에 전달하도록 권했습니다. IPsec이 이후 더 작은 PMTU를 발견하면 SA에 저장하고 L2TP에 통보해야 했습니다. IP 계층에서의 발견은 그 인터페이스를 건너기 전까지는 PPP를 바꾸지 않았습니다.

상태 기반 압축은 또 다른 위험을 보여주었습니다. L2TP가 연결 지향이더라도 IP 위에서는 전달 순서를 강제하지 않았습니다. 패킷 하나의 손실이 이력을 공유하는 압축·암호화 시퀀스 전체를 동기화 이탈시킬 수 있었습니다. RFC는 상태 없는 방식을 선호했습니다. 터널이라는 논리적 형태가 하위 네트워크를 순서 보장 채널로 만들지는 않았습니다.

그러나 결정적인 분리는 신원의 분리였습니다.

PPP는 세션 수립 시점에 사용자를 한 번 인증할 수 있었습니다. 그 신원은 패킷마다 다시 검사되지 않았습니다. IKE는 신원—대개 기기—을 인증하고, IPsec이 매 패킷을 변경과 재전송 공격으로부터 보호하는 데 쓰는 키를 도출했습니다. 반복되는 증명은 강력했지만, 반복되는 것은 IKE의 주장이었습니다.

공유 기기에서 이것은 틈을 만들었습니다. PPP가 앨리스를 식별했더라도 IKE가 노트북을 인증했다면, ESP는 패킷이 노트북 키의 소유자에게서 왔다는 것만 증명합니다. 앨리스가 그 패킷을 만든 로컬 프로세스나 사용자라는 것은 증명하지 않습니다. 트래픽 분리가 없으면 같은 기기의 다른 사용자가 열려 있는 터널을 이용할 수 있었습니다.

IKE 안에서 사용자를 인증하면 틈의 일부를 막을 수 있었지만 정책 적용을 대신하지 못했습니다. 클라이언트는 그 사용자의 트래픽만 터널에 들어간다고 보장해야 했습니다. 선언된 신원과 실질적인 격리는 여전히 서로 다른 사실이었습니다.

인증서는 질문을 등록(enrolment)으로 옮겼습니다. 하나의 LNS는 여러 인증 기관을 신뢰하고 서로 다른 폐기 실무를 적용할 수 있었습니다. 기기 인증서의 가치는 허위 신원 아래서 획득을 막는 프로세스의 가치에 달려 있었습니다. 스마트카드는 일부 사용자 키를 더 잘 보호했지만, 조직이 승인된 하드웨어에 묶으려던 자격 증명의 이동을 허용할 수도 있었습니다. 암호 지원 그 자체가 행정적 권위를 정의하지는 않았습니다.

그룹 사전 공유 키는 더 취약했습니다. 원격 접속에서 클라이언트의 주소은 동적이었습니다. Main Mode에서 서버는 신원을 받기 전에 키를 골라야 할 수 있었습니다. 모두가 하나의 키를 공유하면 선택 문제는 해결되지만 개별성이 파괴됩니다. 비밀을 아는 누구나 특정 상대가 아니라 그룹의 소속을 증명할 수 있었습니다. 기술된 모델에서 그런 주체는 LNS로 위장해 이후 레거시 PPP 방식의 비밀번호를 공격할 수 있었습니다. RFC는 원격 접속 환경에서 LNS를 인증하는 데 그룹 키를 쓰지 말 것을 권고했습니다.

Aggressive Mode는 이른 신원으로 키를 고를 수 있게 했지만 그 신원을 노출했습니다. 인증서는 더 잘 확장되었지만 기관, 등록, 폐기가 필요했습니다. 모든 비용을 없애는 선택지는 존재하지 않았습니다. "인증됨"이라는 꼬리표는 어떤 교환이 선택되었는지를 감추었습니다.

L2TP가 시작되는 위치는 또한 누가 보호를 관찰할 수 있는지를 바꿨습니다. 필수 터널(compulsory tunnel)에서 클라이언트는 PPP를 LAC에 넘기고, LAC–LNS 구간이 L2TP/IPsec으로 간다는 사실 자체를 모를 수도 있었습니다. LNS는 SA의 속성을 조회할 수 있었지만, 클라이언트는 자신이 LAC까지 가는 링크의 증거로 그 SA를 쓸 수 없었습니다. 비대칭적인 지식이었습니다.

자발적 터널(voluntary tunnel)에서는 클라이언트가 L2TP를 시작하고 LNS까지의 SA를 알 수 있었습니다. 클라이언트와 LNS는 PPP 암호화나 압축을 더 잘 조정하고 어떤 중복은 피할 수 있었습니다. 그러나 LNS 뒤 구간은 그 증명에 들어가지 않았습니다. RFC 자체가 종단 간 보안은 표준화하지 않는다고 명시했습니다.

이것이 가장 오래 지속된 공헌이었습니다. RFC 3193은 단순히 IPsec을 L2TP "아래에" 놓지 않았습니다. L2TP가 보안 정책에 어떤 사실을 넘겨야 하는지, IKE가 응용에 어떤 결과를 돌려주어야 하는지, 어떤 신원들이 증명 범위 밖에 남는지를 정의했습니다. 상호운용성은 제한된 증명들을 조율하는 데 달려 있었고, 그중 하나를 전부의 진실로 격상시키는 데 달려 있지 않았습니다.