AH인가 ESP인가? 패킷이 무엇을 보호해야 하는지로 정한다

두 IPsec 제안이 같은 SHA 기반 무결성 알고리즘을 언급하면서도 서로 다른 보호 프로토콜을 요구할 수 있다. AH와 ESP는 하나의 인증 설정에 대한 두 가지 표기가 아니다. 먼저 프로토콜을 읽고, 다음으로 그 알고리즘을, 다음으로 모드를 읽으면 모호함의 대부분이 사라진다. AH는 전송 중에 변하지 않는 IP 헤더 필드를 포함해 패킷을 인증하고, ESP는 자신이 캡슐화한 내용을 인증하고 암호화하며 바깥 헤더는 그대로 둔다. 이 차이가 어떤 해시 이름보다 더 많은 구축을 좌우한다.

AH가 덮고 ESP가 덮지 않는 것

AH는 무결성, 데이터 출처 인증, 그리고 자신이 정의하는 재전송 방지 서비스를 제공하며 기밀성은 전혀 제공하지 않는다. 그 범위에는 상위 계층 데이터와, 규칙이 불변으로 보는 IP 헤더 필드가 포함된다. 바로 ESP가 전송 모드에서 밖에 두는 부분이다. 요구사항이 IP 헤더 자체를 인증해야 한다고 하면 그에 답하는 프로토콜은 AH다.

이 범위가 바로 AH가 현장에서 취약한 이유이기도 하다. TTL, 헤더 체크섬, 일부 옵션 같은 가변 필드는 라우터가 다시 쓸 수 있어 인증할 수 없으므로, 프로토콜은 검사값을 계산하기 전에 이들을 영으로 만든다. 따라서 주소를 다시 쓰는 모든 것은 정책만이 아니라 계산을 깨뜨린다.

NAT가 선택을 제약으로 바꾼다

주소 변환은 AH가 방금 인증한 IP 헤더의 출발지나 목적지를 다시 쓴다. 그래서 무결성 검사는 먼 쪽에서 실패하며, 읽을 수 있는 메시지가 아니라 프로토콜 오류로 실패한다. ESP는 바깥 헤더를 인증하지 않으므로 NAT 통과와 함께 쓰는 ESP는 동작하고 NAT 뒤의 AH는 동작하지 않는다. 양쪽 끝이 평범한 라우터 뒤에 있는 터널에서 이것이 가장 먼저 나타난다. 따라서 첫 질문은 어느 프로토콜이 더 강한가가 아니라, 두 끝 사이에 변환 장치가 있는가이다.

있다면 AH는 빠지고, 대화는 ESP와 그 알고리즘 선택으로 넘어간다. 이것은 선호가 아니라 제약이며, 그래서 결정의 마지막이 아니라 처음에 놓인다.

모드가 질문을 배가한다

ESP는 전송 모드에서 상위 계층 페이로드를 보호하고 IP 헤더는 그대로 둔다. 터널 모드에서는 안쪽 IP 헤더를 포함한 내부 패킷 전체를 캡슐화해 보호한다. AH도 같은 두 모드를 가지므로, AH냐 ESP냐는 알고리즘을 고르기 전에 실제로 네 가지 조합이다.

복합 모드 ESP 알고리즘은 두 번째 프로토콜 없이 무결성을 결정한다. AES-GCM과 ChaCha20-Poly1305는 하나의 구성에서 인증과 암호화를 하므로, 위에 AH를 더해도 얻는 것이 없고 헤더 하나와 협상 한 번을 더 쓴다. 구조는 AH와 ESP를 함께 허용하지만, 실무적 질문은 게이트웨이와 릴리스가 그 조합을 지원하는지, 나중에 누가 유지보수할 수 있는지이다.

AH만 쓰던 설계의 정직한 대체

무결성만 제공하는 ESP 변형은 알고리즘을 유지하고 암호화 주장을 흉내 내는 대신 포기하며, NAT도 통과한다. 기존 설계가 기밀성 없는 인증이 필요해 AH를 썼다면, 그 변형이 곧 직접적인 번역이며, 메모를 붙인 암호화 터널이 아니다.

제안에 ESP가 있다는 것도 암호화의 증거가 아니다. 암호화 알고리즘을 읽어야 한다. NULL 항목은 무결성만, 복합 모드 항목은 둘 다를 뜻한다.

세 가지 질문으로 정한다

기밀성이 필요한지, 경로에 변환 장치가 있는지, 어떤 헤더 필드를 인증해야 하는지 물어야 한다. 이 세 답이 하나의 프로토콜과 하나의 모드를 가리키며, 적어 두는 편이 나중에 RFC를 다시 읽는 것보다 시간이 덜 든다.

그다음 제안된 것이 아니라 수용된 것을 검증한다. ip xfrm state 는 설치된 연관의 프로토콜, 모드, 알고리즘을 보여 주며, 불일치가 있으면 아무것도 설치되지 않는다. 이는 의도한 보호 없이 올라오는 터널보다 깔끔한 실패다.

인증 실패, 선택자 범위, 라우팅 결함은 이 선택과 분리해 두어야 한다. 증상이 각각 다르며, 선택자 문제를 프로토콜 탓으로 돌리면 이유 없이 해시를 바꾸며 하루를 보내는 확실한 방법이다.