IPsec의 AH와 ESP는 무엇을 보호하나

AH는 IP datagram에 무결성과 데이터 원점 인증을 제공하고, 선택하면 재전송 방지도 지원합니다. 보호 가능한 범위의 IP 헤더와 상위 데이터에 적용되지만 전송 중 예측할 수 없이 바뀌는 모든 헤더 필드를 보호하는 것은 아닙니다.

ESP는 SA에서 선택한 옵션에 따라 기밀성, 무결성·원점 인증, 재전송 방지 등을 제공할 수 있습니다. ESP라는 이름만 보고 항상 암호화된다고 답할 수 없습니다. 사례는 새로 만든 교육용 패킷이며 실제 제품 설정을 나타내지 않습니다.

AH와 ESP는 우선 보호 서비스의 질문으로 나눕니다

IPsec의 AH(Authentication Header)와 ESP(Encapsulating Security Payload)는 패킷 보호에 서로 다른 옵션을 제공합니다. AH는 IP datagram에 대한 connectionless integrity와 data-origin authentication을 제공하고, 선택된 경우 replay protection도 지원합니다. 기밀성을 제공하지 않으므로 AH만 적용한 패킷의 데이터 내용을 숨기는 기능은 없습니다. AH는 가능한 범위에서 IP header와 상위 프로토콜 데이터를 인증하지만, 라우터를 지나면서 값이 달라질 수 있는 일부 필드는 송신 시 값을 미리 알기 어렵기 때문에 보호하지 못합니다.

ESP는 confidentiality(기밀성), data-origin authentication, connectionless integrity, anti-replay 및 제한된 traffic-flow confidentiality 중 일부 서비스를 제공할 수 있습니다. 어떤 조합을 실제 쓰는지는 Security Association(SA) 설정과 배치 위치에 달려 있습니다. RFC 4303은 무결성만, 기밀성만 또는 기밀성과 무결성을 조합한 서비스 선택을 설명합니다. 그러므로 ‘ESP는 암호화’라고만 말하면 핵심 선택 조건을 놓칠 수 있습니다. 문제에서 묻는 서비스와 SA가 선택한 옵션을 함께 답해야 합니다.

주소와 페이로드의 요구를 먼저 정하면 답이 선명합니다

서버 A가 서버 B에 업무 자료를 보내는 가상 장면을 생각해 봅시다. 요구사항이 ‘전송 중 패킷이 바뀌었는지 확인하고 송신 peer가 맞는지 검증’이라면 AH가 제공하는 무결성·원점 인증을 검토할 수 있습니다. 다만 AH를 추가했다고 자료 내용이 숨겨지지는 않습니다. 요구사항에 기밀성이 있다면 선택 가능한 ESP의 confidentiality service와 SA 설정을 확인합니다. 두 서비스를 모두 요구할 때 ESP에서 기밀성과 무결성을 함께 선택할 수도 있습니다. 키 관리와 알고리즘의 현재 적합성은 이 비교표만으로 판단하지 않습니다.

패킷 헤더의 TTL이나 일부 경로 관리 값은 전송 중 바뀔 수 있습니다. AH는 이러한 예측 불가능한 변경 필드까지 그대로 보호한다고 보장하지 않습니다. 따라서 ‘AH는 전체 IP 헤더를 전부 무결성 검사한다’고 단순화하지 말고 변경 가능한 헤더 값과 보호 대상 범위를 확인합니다. ESP도 보통 IP header 자체를 기본 보호하지 않으므로 어떤 mode에서 어떤 바이트가 보호되는지 추가로 살펴야 합니다. 이는 #39의 transport/tunnel packet 구조와 이어지는 별도 판단입니다.

보호 목표에서 설정 근거까지 다섯 단계를 따릅니다

1. 요구사항을 기밀성, 무결성, 원점 인증, 재전송 방지로 각각 적습니다.
2. AH 또는 ESP가 그 서비스를 제공하는지 표준 문서에서 확인합니다.
3. 패킷의 mode, SA 옵션과 실제 협상 결과를 분리해 검토합니다.
4. 동적 IP header 값과 상위 payload 중 어디까지 보호되는지 범위를 기록합니다.
5. 구성 및 로그를 확보하기 전에는 서비스가 켜졌다고 추측하지 않습니다.

AH와 ESP는 이름을 외우는 문제보다 요구와 서비스의 대응을 설명하는 문제입니다. 예를 들어 암호화하지 않으면서 무결성만 요구하는 구성은 ESP의 무결성 전용 선택으로도 가능할 수 있어 AH가 유일한 답은 아닙니다. 반면 IP header의 특정 변경 필드까지 보호하려는 요구는 AH의 범위 한계를 검토하게 합니다. 같은 프로토콜도 transport/tunnel mode, endpoint와 SA 옵션에 따라 실제 패킷의 보호 영역이 바뀔 수 있습니다. 짧은 답에는 이 조건을 최소 한 가지 적으세요.

프로토콜 이름을 서비스 보장으로 바꾸지 않습니다

흔한 실수는 ‘ESP는 encryption, AH는 authentication’이라는 한 줄만 외우는 것입니다. ESP도 무결성만 선택하는 조합을 지원하며, AH도 원점 인증과 무결성을 제공하면서 IP header의 일부를 보호할 수 있습니다. 또 AH가 인증한다는 사실을 모든 헤더 바이트나 실제 사용자 신원까지 검증한다고 확대하면 안 됩니다. IPsec peer와 SA가 제공하는 암호학적 속성의 범위와, 네트워크 사용자의 애플리케이션 권한 판단은 다른 계층의 문제입니다.

목표 서비스와 빠진 보장을 함께 답해 봅니다

회상 연습: 가상의 SA에 AH가 적용되어 무결성 검증을 하지만 응용 데이터 내용도 숨기고 싶습니다. 무엇이 부족하며 ESP를 선택한다면 어떤 설정 근거를 확인하나요? AH에는 기밀성이 없으므로 내용이 감춰지지 않습니다. ESP의 기밀성 service를 SA가 실제로 선택했는지, 필요한 무결성·원점 인증과 replay 설정도 협상·구성됐는지 확인해야 합니다. 사례는 교육을 위해 직접 만들었으며 실제 출제 문항 또는 집중 180제의 카드라고 주장하지 않습니다. 상품 구성은 /decks/security#focus-180에서 확인할 수 있습니다.