핵심 인사이트 (3줄 요약)

  1. 본질: AH는 빈출 주제와 용어에서 핵심 동작과 제약을 이해하게 해 주는 개념이다.
  2. 가치: AH를 이해하면 구분 명확성과 설명력 사이의 균형을 더 정확히 볼 수 있다.
  3. 판단 포인트: 설계 시에는 개념 자체보다 적용 조건, 운영 복잡도, 인접 기술과의 경계를 함께 판단해야 한다.

Ⅰ. 개요 및 필요성

  • 개념: AH (Authentication Header)는 IP 패킷의 인증 및 무결성을 보장하기 위해 IETF (Internet Engineering Task Force)에서 정의한 IPSec 보안 프로토콜이다. 패킷의 내용이 전송 중에 변경되지 않았으며, 송신자가 위장되지 않았음을 수신자가 검증할 수 있게 해주는 '디지털 봉인' 역할을 한다.
  • 필요성: 기존의 평문 IP 기반 통신에서는 공격자가 패킷을 가로채어 출발지 IP 주소를 조작 (IP Spoofing)하거나 데이터 내용을 몰래 변경하더라도 수신자가 이를 알아챌 방법이 없다. 금융 거래나 라우팅 정보 교환 시에는 내용이 암호화되지 않아도 무방하더라도 내용이 조작되지 않았다는 '확실한 증명'이 반드시 필요하다.
  • 💡 비유: AH는 중요한 공문서 봉투 겉면에 찍힌 '밀랍 인장 (Wax Seal)'과 같다. 투명한 봉투라 누구나 안의 글씨 (평문 데이터)를 읽을 수는 있지만, 도중에 누군가 글자를 고치거나 위조 서명을 넣으려 하면 인장이 깨지기 때문에 수신자는 즉시 조작 사실을 알아챌 수 있다.
  • 등장 배경 및 발전 과정:
    1. IP 스푸핑 및 세션 하이재킹 위협: 1990년대 초 인터넷 해킹 기법이 발전하면서, 타인의 IP로 위장하여 통신에 끼어드는 공격이 성행했다.
    2. 무결성 프로토콜의 필요성 대두: 기밀성(암호화)은 연산 비용이 크고 각국의 수출 통제 규제를 받았기 때문에, 순수하게 인증과 무결성만 제공하는 가벼운 프로토콜의 필요성이 제기되었다.
    3. AH와 ESP의 분리 표준화 (RFC 2402, 4302): IPSec 프레임워크는 강력한 인증(AH)과 암호화(ESP)를 분리하여 설계함으로써, 환경과 요구사항에 맞게 취사선택할 수 있는 유연한 보안 아키텍처를 완성했다.

AH 도입 전 IP 스푸핑 공격의 위협과 AH 도입 후의 방어 메커니즘을 구조도로 시각화하면 무결성 인증이 왜 중요한지 명확해진다.

  ┌─────────────────────────────────────────────────────────────┐
  │              IP 스푸핑 위협 및 AH를 통한 방어 원리              │
  ├─────────────────────────────────────────────────────────────┤
  │                                                             │
  │  [AH 미적용 시 IP Spoofing 공격]                                │
  │  해커 (IP: 1.1.1.1) ───────────▶ 목적지 서버                     │
  │  가짜 패킷: [ Src IP: 정상PC(10.0.0.2) | Data: "돈을 보내라" ]     │
  │  ⚠ 서버: "정상PC(10.0.0.2)가 보낸 명령이군. 실행!" (위장 성공)         │
  │                                                             │
  │  [AH 적용 시 방어 성공]                                          │
  │  해커 (IP: 1.1.1.1) ───────────▶ 목적지 서버                     │
  │  조작 패킷: [ Src IP: 정상PC | AH Header | Data ]               │
  │                                                             │
  │  서버의 AH 검증 프로세스:                                        │
  │   1. AH에 포함된 무결성 해시(ICV) 확인                            │
  │   2. 서버가 수신된 (IP헤더+데이터+비밀키)로 해시 재계산              │
  │   3. 수신된 ICV ≠ 계산된 ICV (해커는 정상PC의 비밀키를 모름)          │
  │  ✅ 서버: "해시값이 불일치한다! IP가 조작된 패킷이군. 폐기!"            │
  └─────────────────────────────────────────────────────────────┘

[다이어그램 해설] IPSec AH가 없는 환경에서 목적지 서버는 IP 헤더의 출발지 주소 (Source IP)를 전적으로 신뢰하여 작동한다. 따라서 해커가 자신의 IP를 속여 패킷을 전송하면 서버는 이를 막아낼 수 없다. 그러나 AH를 적용하면 송수신자만 아는 공유 비밀키 (Shared Secret Key)를 이용해 전체 패킷에 대한 해시 (MAC, Message Authentication Code)를 생성하여 패킷에 부착한다. 해커가 IP 헤더를 조작하려 해도 비밀키를 모르기 때문에 올바른 해시값을 다시 계산하여 붙일 수 없다. 결국 수신 서버에서 해시 검증 (ICV 검증)에 실패하여 조작된 패킷은 즉시 버려지며 (Drop), 완벽한 데이터 발신자 인증이 이루어진다.

  • 📢 섹션 요약 비유: 서류를 보낼 때 보내는 사람의 지문(비밀키)으로 서명한 위조 방지 홀로그램 스티커(AH)를 붙여서, 도중에 누군가 잉크를 덧칠하거나 보낸 사람 이름을 바꾸면 스티커가 깨지도록 설계한 것과 같습니다.

Ⅱ. 아키텍처 및 핵심 원리

구성 요소

요소명역할내부 동작프로토콜비유
SPI (Security Parameters Index)보안 연관 (SA) 식별수신자가 이 패킷을 처리할 알고리즘/키를 찾기 위한 32비트 식별자32-bit Integer자물쇠를 열 열쇠 번호
Sequence Number재생 공격 (Anti-replay) 방지패킷마다 1씩 증가하는 카운터, 이미 받은 번호면 폐기32/64-bit Counter은행 OTP 일회용 비밀번호
ICV (Integrity Check Value)무결성 및 인증 검증IP 헤더, AH 헤더, 페이로드를 HMAC (MD5/SHA) 알고리즘으로 계산한 해시값HMAC-SHA256 등위조 방지 밀랍 인장
Next Header상위 프로토콜 지정AH 헤더 다음에 오는 페이로드의 종류 (TCP, UDP 등) 명시8-bit Protocol ID봉투 안의 내용물 종류
Payload LengthAH 헤더의 길이 지정전체 패킷 내에서 AH 헤더가 차지하는 바이트 수8-bit Length봉인 스티커의 크기

AH 패킷의 물리적 구조와 인증 범위

AH의 핵심은 패킷에서 '어디까지를 인증 범위(Authentication Coverage)로 삼는가'이다. ESP가 IP 헤더를 보호하지 않는 반면, AH는 IP 헤더의 '고정 필드'까지 인증 영역에 포함시켜 더 넓은 무결성을 제공한다.

  ┌──────────────────────────────────────────────────────────────────┐
  │                 IPSec AH의 패킷 캡슐화 및 인증 범위 (수송 모드)        │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │ [IPSec AH 수송 모드 패킷 구조]                                     │
  │                                                                  │
  │     ←───────────────────── 인증 범위 (MAC 계산 영역) ─────────────────→│
  │ ┌───────────────┬───────────────┬───────────────┬────────────────┐ │
  │ │ Orig IP Header│   AH Header   │   TCP Header  │      Data      │ │
  │ │(가변 필드 제외) │ (ICV 필드 제외) │               │                │ │
  │ └───────────────┴───────────────┴───────────────┴────────────────┘ │
  │                                                                  │
  │ [AH Header 세부 구조 (RFC 4302)]                                   │
  │  0                   1                   2                   3   │
  │  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 │
  │ ┌───────────────┬───────────────┬───────────────────────────────┐│
  │ │ Next Header   │ Payload Len   │          RESERVED             ││
  │ ├───────────────┴───────────────┴───────────────────────────────┤│
  │ │                  Security Parameters Index (SPI)              ││
  │ ├───────────────────────────────────────────────────────────────┤│
  │ │                      Sequence Number                          ││
  │ ├───────────────────────────────────────────────────────────────┤│
  │ │                                                               ││
  │ │            Integrity Check Value (ICV) - 가변 길이                ││
  │ │                                                               ││
  │ └───────────────────────────────────────────────────────────────┘│
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] AH는 수송 모드 적용 시 기존 IP 헤더와 상위 계층 (TCP/UDP) 사이에 위치한다. AH의 인증 범위(Authentication Coverage)는 놀랍게도 IP 헤더, AH 헤더 자신, 그리고 상위 페이로드 전체를 포괄한다. 단, 라우터를 거치며 값이 필연적으로 변하는 IP 헤더의 가변 필드 (Mutable Fields, 예: TTL, Header Checksum, TOS 등)는 ICV 계산을 할 때 임시로 '0'으로 설정하여 계산에서 제외한다. 이를 통해 라우터를 정상적으로 통과하면서도 IP 주소(고정 필드)의 무결성을 지켜낸다. AH 헤더 내부는 다음 헤더를 가리키는 포인터, SA 식별용 SPI, 재생 공격 방어용 Sequence Number, 그리고 최종 해시값인 ICV로 구성된다.

심층 동작 원리 (무결성 검증 및 재생 공격 방어)

AH의 송수신 처리 메커니즘은 해시 연산과 카운터 윈도우 검증으로 이루어진다.

① 전송측 ICV 계산: 송신자는 보호할 IP 패킷을 구성하고, 가변 필드를 0으로 마스킹한다. ② 해싱 적용: 마스킹된 패킷 전체와 양단 간에 사전 합의된 비밀키(Shared Key)를 결합하여 HMAC (Hash-based Message Authentication Code) 함수 (예: HMAC-SHA256)를 돌려 고유한 ICV 값을 얻어낸다. ③ AH 부착 및 전송: 계산된 ICV를 AH 헤더에 기록하고, 증가시킨 Sequence Number를 함께 담아 인터넷으로 전송한다. ④ 수신측 Anti-replay 검증: 수신자는 AH의 Sequence Number를 확인하여 슬라이딩 윈도우 (Sliding Window, 보통 64 패킷) 내에 있는지, 이전에 받은 적이 있는 패킷인지 검사한다. 중복/과거 패킷이면 즉시 폐기 (재생 공격 방어). ⑤ 수신측 ICV 재계산 및 비교: Sequence Number를 통과하면 수신자는 동일한 비밀키로 패킷의 ICV를 재계산한다. 패킷에 적힌 ICV와 재계산된 ICV가 완벽히 일치하면 인증 및 무결성이 확인된 것이며, 상위 계층 (TCP)으로 데이터를 올려보낸다.

  • 📢 섹션 요약 비유: 송신자가 서류에 고유 번호(시퀀스 넘버)와 비밀 도장(ICV)을 찍어 보내면, 수신자는 돋보기로 도장의 진위를 확인하고 번호표 대장을 확인해 어제 낸 서류를 오늘 다시 내는 사기꾼(재생 공격)을 걸러내는 치밀한 검문소 역할을 합니다.

Ⅲ. 비교 및 연결

IPSec의 양대 산맥인 AH와 ESP는 보호하는 영역과 암호화 제공 여부에서 극명한 차이를 보인다.

비교 항목AH (Authentication Header)ESP (Encapsulating Security Payload)판단 포인트
기밀성 (암호화)❌ 지원 안 함 (평문 전송)✅ 지원 (데이터 암호화)데이터 은닉이 필수적인가?
무결성 / 인증✅ 지원 (IP 헤더 일부 + 페이로드 전체)✅ 지원 (ESP 헤더 + 페이로드만)외부 IP 헤더의 인증 여부
NAT 통과 (NAT Traversal)❌ 불가능 (IP 변조 시 인증 깨짐)✅ 가능 (NAT-T, UDP 캡슐화 사용 시)공유기/방화벽 통과 필수성
IP 헤더 보호 범위출발/목적지 IP 등 고정 필드 보호외부 IP 헤더 보호 안 함스푸핑에 대한 엄격한 방어 필요성
프로토콜 번호 (IP 프로토콜 필드)5150방화벽 정책 예외 처리 시

현대 네트워크 설계에서 AH와 ESP의 생존을 가른 가장 큰 기술적 분기점인 'NAT 통과 가능성'을 시각화하면 다음과 같다.

  ┌──────────────────────────────────────────────────────────────────┐
  │                 NAT 환경에서의 AH와 ESP의 동작 차이 비교               │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │ [AH의 NAT 통과 실패 (인증 범위 충돌)]                                 │
  │  송신자 (10.0.0.2) ───▶ [ NAT 라우터 ] ───▶ 인터넷 ───▶ 수신자          │
  │  (AH: Src=10.0.0.2로 ICV 계산)    │(Src를 203.0.113.5로 변경)     │
  │                                   │                              │
  │  수신자 검증: 수신된 Src IP(203.0.113.5)로 ICV 재계산                 │
  │  결과: 원본 ICV(10.0.0.2 기반) ≠ 계산된 ICV(203.x 기반)              │
  │  💥 AH 무결성 검증 실패! 패킷 무조건 폐기 (Drop). NAT와 절대 공존 불가. │
  │                                                                  │
  │ [ESP의 NAT 통과 성공 (NAT-T 적용 시)]                                 │
  │  송신자 (10.0.0.2) ───▶ [ NAT 라우터 ] ───▶ 인터넷 ───▶ 수신자          │
  │  (ESP: IP 헤더는 인증에서 제외됨) │(Src를 203.0.113.5로 변경)     │
  │                                   │                              │
  │  수신자 검증: ESP는 IP 헤더가 아닌 '페이로드'에 대해서만 인증 수행        │
  │  결과: IP가 변조되어도 페이로드 해시는 일치함                          │
  │  ✅ ESP 무결성 검증 성공! (IP 주소가 바뀌어도 통신 유지)                 │
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] AH가 가진 가장 치명적인 아킬레스건은 바로 'IP 헤더 인증'이다. AH는 강력한 방어를 위해 출발지 IP 주소를 인증 알고리즘에 포함시킨다. 그런데 NAT(공유기) 장비를 지나면 필연적으로 출발지 사설 IP가 공인 IP로 변환(조작)된다. 수신자는 변경된 공인 IP를 바탕으로 해시(ICV)를 재계산하므로, 송신자가 사설 IP로 계산했던 원본 해시값과 무조건 불일치하게 된다. 즉, AH는 NAT 환경에서 모든 정상 패킷을 '조작된 공격 패킷'으로 오인하여 폐기한다. 반면 ESP는 외부 IP 헤더를 인증 대상에서 제외하므로 NAT 환경에서도 NAT-T 우회 기술을 통해 성공적으로 통신할 수 있다. 이로 인해 현대 인터넷에서 AH의 사용은 급감했다.

과목 융합 관점

  • 네트워크 보안 (Network Security): BGP나 OSPF와 같은 라우팅 프로토콜 정보 교환 시, 라우팅 테이블 내용이 기밀일 필요는 없으나 중간에 공격자가 라우팅 정보를 위조하여 트래픽 방향을 트는 것 (Routing Blackhole, MITM)은 치명적이다. 이때 데이터 암호화 오버헤드 없이 강력한 출발지 인증을 제공하는 AH가 OSPFv3 등에서 채택되곤 한다.

  • IPv6 아키텍처: IPv6는 본질적으로 NAT가 필요 없을 정도로 주소 공간이 광활하므로 엔드 투 엔드(End-to-End) 공인 IP 통신이 가능하다. IPv6의 확장 헤더 구조(Extension Header)에는 AH가 기본적으로 정의되어 있으며, NAT 충돌 문제가 없는 순수 IPv6 환경에서는 AH의 방어력이 다시금 빛을 발할 수 있다.

  • 📢 섹션 요약 비유: AH는 겉포장지(IP 헤더)까지 통째로 코팅해버리는 방식이라 배송 중 우체국이 분류 스티커(NAT 주소 변환)를 붙일 수 없게 만들어버리는 치명적 단점이 존재하는 것과 같습니다.

Ⅳ. 실무 적용 및 기술사 판단

  1. 시나리오 — 클라우드 VPC 내부의 마이크로서비스 간 무결성 보장: NAT 장비가 개입하지 않는 동일한 AWS VPC (Virtual Private Cloud) 또는 온프레미스 사설망 내부에서, 수천 개의 마이크로서비스 간에 교환되는 API 호출이 위조되지 않았음을 가벼운 오버헤드로 증명해야 하는 상황. 아키텍트는 암호화 부하가 큰 ESP 대신, IP 헤더 스푸핑까지 막아주는 AH 기반의 수송 모드 IPSec 정책을 내부에 배포하여 고성능 제로 트러스트 인증을 구현할 수 있다.
  2. 시나리오 — BGP 라우팅 피어링 보안 인증: 서로 다른 통신 사업자(ISP) 라우터 간에 BGP 피어링을 맺을 때, 제3자가 BGP 업데이트 메시지를 위조하여 트래픽을 가로채는 공격을 막아야 한다. 이때 라우팅 정보 자체는 평문(Public)이므로 암호화가 필요 없다. 엔지니어는 라우터 간 BGP 세션에 MD5 인증이나 IPSec AH를 적용하여 패킷의 출발지와 내용 무결성을 수학적으로 보증하는 정책을 세워야 한다.
  3. 시나리오 — IPSec NAT-T 환경의 VPN 구축 시도 중 장애: 주니어 엔지니어가 본사와 지사 간 VPN을 구성하며 보안을 극대화하겠다며 ESP+AH 조합 모드를 강제했다. 그런데 지사 방화벽(NAT)을 통과하는 순간 모든 VPN 세션이 드롭되는 장애가 발생했다. 시니어 아키텍트는 AH가 NAT를 통과할 수 없다는 설계적 한계를 짚어주고, 정책을 ESP 단독(인증+암호화) 터널 모드 + NAT-T 허용으로 즉시 롤백하여 통신을 복구한다.

AH가 제공하는 또 다른 핵심 기능인 '재생 공격(Replay Attack) 방어 메커니즘'의 내부 윈도우 관리를 시각화하면, 수신 측의 정교한 시퀀스 넘버 검증 로직을 알 수 있다.

  ┌──────────────────────────────────────────────────────────────────┐
  │                 AH의 재생 공격 방어 (Anti-Replay Window)               │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │   [수신자의 Sliding Window (크기 W, 예: 64)]                        │
  │   ───────────────────▶ 시간 (Sequence Number 증가 방향)               │
  │                                                                  │
  │           (이미 받은 오래된 패킷)     (현재 수신 윈도우 범위)                  │
  │         ... 97, 98, 99, 100 │ 101, 102, 103 ... 164 │           │
  │   [폐기 구역: 너무 늦음]        [검증 구역: 정상 수신 대기]   [미래 구역]  │
  │                             └──────── 윈도우 W ───────┘           │
  │                                     ↑                            │
  │                           비트맵으로 수신 여부 체크 (1=수신, 0=미수신)   │
  │                                                                  │
  │   판단 1. Seq=95 수신 → 윈도우 왼쪽(과거) → 즉시 폐기 (Replay 공격)     │
  │   판단 2. Seq=102 수신 → 윈도우 내부, 비트맵=1(이미 받음) → 즉시 폐기    │
  │   판단 3. Seq=105 수신 → 윈도우 내부, 비트맵=0 → 정상 처리 후 비트맵=1로 │
  │   판단 4. Seq=166 수신 → 윈도우 오른쪽(새로운 최신) → 정상 처리 후 윈도우 │
  │                          전체를 오른쪽으로 슬라이딩 (103~166으로 갱신)    │
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] 재생 공격(Replay Attack)은 해커가 정상적인 인증이 완료된 과거의 패킷(예: '계좌로 100만 원 송금하라')을 복사해두었다가 나중에 다시 전송하는 해킹 기법이다. AH는 모든 패킷에 순차적으로 증가하는 Sequence Number(Seq)를 부여한다. 수신자는 보통 64 패킷 크기의 '슬라이딩 윈도우' 비트맵을 유지한다. 만약 해커가 과거 패킷을 다시 보내면, 그 패킷의 Seq는 이미 윈도우의 왼쪽(너무 낡음)에 있거나, 윈도우 내부에 있더라도 이미 수신 확인(비트맵=1)이 된 상태이므로 즉각 폐기된다. 이 정교한 윈도우 메커니즘을 통해 네트워크 지연으로 인한 약간의 순서 뒤바뀜(Out-of-order)은 허용하면서도 악의적인 재생 공격은 완벽히 차단한다.

도입 체크리스트

  • 기술적: 보호해야 할 통신 경로 상에 NAT(공유기)나 PAT 장비가 존재하는가? (존재한다면 AH 사용 불가, ESP 도입) 내부망에서 출발지 IP 위장 검증이 필수적인가?
  • 운영·보안적: AH만 적용할 경우 데이터가 평문으로 스니핑될 위험은 감수할 수 있는가? ESP가 제공하는 '인증' 기능만으로도 충분하지 않고 반드시 IP 헤더 고정 필드까지 인증해야 하는 강력한 근거가 있는가?

안티패턴

  • 외부 인터넷 구간의 VPN 구성 시 AH 강제 사용: 오늘날 퍼블릭 인터넷은 100% NAT 라우터를 경유한다고 보아도 무방하다. 이곳에 AH 터널/수송 모드를 고집하는 것은 네트워크 아키텍처에 대한 무지의 소치이며 즉각적인 서비스 단절을 낳는다.

  • AH와 ESP를 무조건 중복 적용 (AH+ESP): ESP 자체에도 HMAC 기반의 인증(Authentication) 기능이 포함되어 있다. 극도로 민감한 망이 아닌 일반 기업망에서 AH와 ESP를 동시에 이중으로 씌우는 것은 불필요한 해시 연산 오버헤드와 패킷 크기(MTU) 증가만 초래하는 전형적인 과잉 설계다.

  • 📢 섹션 요약 비유: 아무리 튼튼한 금고(AH)라도, 택배 기사가 배송지를 바꿔 적어야만 전달할 수 있는 복잡한 현대의 택배 시스템(NAT 환경)에서는 억지로 반송되어버리는 너무 고지식한 보안 장치와 같습니다.

Ⅴ. 기대효과 및 결론

구분최적화 전최적화 후개선 효과
정량ESP (암호화+인증) 사용 시 높은 CPU 오버헤드내부망에 AH (인증 전용) 전면 적용암호화 복호화 오버헤드 제거로 처리량(TPS) 40% 이상 향상
정량재생 공격 방어 부재AH Sequence Number 윈도우 적용동일 패킷 반복 전송을 통한 대역폭 고갈(DDoS) 패킷 100% 차단
정성IP 위장 공격 (Spoofing) 속수무책전체 IP 고정 필드 무결성 검증출발지 인증 신뢰도 확보 및 내부자 위장 침투 (Lateral Movement) 방어

미래 전망

  • IPv6 확산에 따른 재부상: 전 세계적으로 IPv4가 고갈되고 IoT 기기 중심의 IPv6 전환이 가속화되면서 NAT의 필요성이 사라지는 추세다. End-to-End 라우팅이 투명해지는 순수 IPv6 환경에서는 AH의 NAT 충돌 단점이 사라지므로, 오버헤드가 적은 경량 인증 프로토콜로서의 가치가 재조명될 가능성이 높다.
  • 하드웨어 가속기(NIC) 탑재: 최신 스마트 NIC(Network Interface Card)와 DPU(Data Processing Unit) 장비들은 AH와 ESP의 HMAC 해시 연산을 CPU 대신 하드웨어 계층에서 오프로딩(Offloading)하여 와이어 스피드(Wire-speed) 100Gbps 환경에서도 지연 없는 무결성 검증을 수행하도록 진화하고 있다.

참고 표준

  • RFC 4302: IP Authentication Header (AH 프로토콜의 표준 규격서)
  • RFC 2104: HMAC: Keyed-Hashing for Message Authentication
  • IEEE 802.1AE (MACsec): L2 계층의 통신 무결성 표준 (네트워크 하위 계층에서 AH와 유사한 역할)

현대 네트워크 보안에서 AH는 암호화를 제공하는 ESP의 그림자에 가려진 프로토콜처럼 보일 수 있다. 그러나 '기밀성'과 '무결성/인증'을 아키텍처 관점에서 철저히 분리하여 설계한 IPSec의 디자인 철학을 가장 잘 보여주는 핵심 구성 요소다.

IPSec 내에서 AH와 ESP가 차지하는 보안 기능 제공의 커버리지를 벤 다이어그램과 매트릭스로 요약하면, 두 프로토콜이 어떻게 보완적 역할을 하는지 확인할 수 있다.

  ┌──────────────────────────────────────────────────────────────────┐
  │              IPSec 보안 기능 커버리지 (AH vs ESP)                   │
  ├──────────────────────────────────────────────────────────────────┤
  │                                                                  │
  │                  [ IPSec 보안 프레임워크 (RFC 4301) ]                 │
  │                                                                  │
  │  ┌──────────────────┐  ┌──────────────────────────────────────┐  │
  │  │        AH        │  │                 ESP                  │  │
  │  │ ┌──────────────┐ │  │ ┌──────────────┐ ┌─────────────────┐ │  │
  │  │ │무결성/인증 보장│ │  │ │기밀성(암호화)보장│ │ 페이로드 무결성/│ │  │
  │  │ │(IP헤더 + 페이로드│ │  │ │(순수 데이터 은닉)│ │ 인증 보장       │ │  │
  │  │ │  강력한 스푸핑 방어│ │  │ │  NAT 완벽 통과  │ │ (IP헤더 제외)   │ │  │
  │  │ └──────────────┘ │  │ └──────────────┘ └─────────────────┘ │  │
  │  │    [재생공격 방어]   │  │             [재생공격 방어]              │  │
  │  └──────────────────┘  └──────────────────────────────────────┘  │
  │                                                                  │
  │  현대의 결론: ESP의 [인증 보장] 기능 발전과 NAT 환경의 고착화로 인해,         │
  │             대부분의 방화벽/VPN 벤더는 ESP를 단독으로 사용하는 것을 표준으로 │
  │             삼고, AH는 특수 목적망(IPv6, BGP 등)에서만 제한적으로 활용한다.│
  └──────────────────────────────────────────────────────────────────┘

[다이어그램 해설] AH는 무결성(Integrity)과 출발지 인증(Authentication)에 집중하여 IP 헤더까지 강력하게 보호한다. ESP는 본래 암호화(Confidentiality)를 위해 탄생했으나, 진화를 거듭하며 자체적인 인증(Auth Trailer) 기능까지 추가로 장착하게 되었다. 비록 ESP의 인증이 외부 IP 헤더를 보호하지는 못하지만, 페이로드를 완벽히 보호하고 NAT를 무사히 통과한다는 엄청난 실무적 장점이 있다. 그 결과 현대 실무에서는 굳이 AH+ESP를 같이 쓰지 않고, ESP 단독 사용만으로 기밀성, 페이로드 무결성, 재생 공격 방어, NAT 통과라는 네 마리 토끼를 모두 잡는 아키텍처가 시장의 표준(De facto standard)이 되었다.

  • 📢 섹션 요약 비유: AH는 내용물을 투명하게 유지하되 위조를 절대 용납하지 않는 엄격한 유리병과 같아서, 안의 내용물을 감추고 유연하게 배송해야 하는 현대의 불투명한 택배 시장(ESP)에 자리를 내주었지만, 그 무결성 철학만큼은 여전히 살아 숨 쉬고 있습니다.

📌 관련 개념 맵

개념연결 포인트
IPSec 터널/수송 모드현재 개념이 등장하기 전에 갖춰야 할 배경이나 인접 선행 개념이다.
정의 (Definition)용어의 시작점을 분명하게 만든다.
비교 (Comparison)헷갈리는 개념의 경계를 드러낸다.
ESP현재 개념이 확장되거나 적용 단계로 이어질 때 자주 함께 언급된다.

📈 관련 키워드 및 발전 흐름도

[선행 개념: IPSec 터널/수송 모드]
    │
    ▼
[현재 개념: AH]
    │
    ├──▶ [확장 A: ESP]
    └──▶ [확장 B: 컨텍스트 기반 용어 해석]

AH는 IPSec 터널/수송 모드에서 출발해 현재 메커니즘을 정교화하고, 이후 ESP와 컨텍스트 기반 용어 해석 같은 확장 흐름으로 이어진다고 보면 기억이 오래간다.

👶 어린이를 위한 3줄 비유 설명

  1. 편지를 보낼 때, 친구와 나만 아는 '마법의 비밀 도장(AH)'을 편지 봉투와 내용물에 꾹 찍어 보내는 규칙을 만들었어요.
  2. 중간에 나쁜 악당이 편지를 몰래 가로채서 글자를 지우거나 보낸 사람 이름을 자기 이름으로 고치면, 마법의 도장이 쩍 갈라지면서 깨져버려요.
  3. 친구는 도장이 깨진 편지를 받으면 "아하, 누군가 장난을 쳤구나!" 하고 바로 쓰레기통에 버릴 수 있어서, 절대 가짜 편지에 속지 않게 되는 원리랍니다!