589. IPsec (Internet Protocol Security) 오프로드 가속기

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

본질: IPsec (Internet Protocol Security) 오프로드 가속기는 보안 연관 (Security Association, SA) 조회, ESP (Encapsulating Security Payload) 캡슐화, 암·복호화, 무결성 검증 같은 반복 데이터 평면 작업을 네트워크 인터페이스 카드 (Network Interface Card, NIC) 또는 데이터 처리 장치 (Data Processing Unit, DPU)로 옮기는 구조다.

가치: 25GbE·100GbE급 링크에서 중앙처리장치 (Central Processing Unit, CPU)가 패킷 보호 작업에 잠식되는 문제를 줄여, 보안 강화를 처리량 하락이 아니라 선로 속도와 낮은 지터로 바꾸는 데 도움이 된다.

판단 포인트: 진짜 의사결정 기준은 "하드웨어 암호화가 있느냐"가 아니라 inline/ lookaside 배치, 알고리즘 지원 범위, SA 수용량, 그리고 인터넷 키 교환 (Internet Key Exchange, IKE)·재키잉 같은 제어 평면이 여전히 호스트에 남는다는 사실까지 함께 보는 것이다.

Ⅰ. 개요 및 필요성

IPsec 오프로드 가속기는 네트워크 계층 보안을 선로 속도에 가깝게 유지하려는 시도에서 나온 구조다. 사이트 간 가상 사설망 (Virtual Private Network, VPN)이나 데이터센터 동서 트래픽 보호에서는 패킷마다 헤더를 분석하고, 어떤 SA를 쓸지 찾고, 시퀀스 번호를 붙이고, 암호화와 인증을 수행해야 한다. 이 과정을 전부 CPU가 맡으면 애플리케이션을 위한 코어보다 "보안을 위한 코어"가 더 많이 필요해지는 역전 현상이 생긴다.

특히 패킷 크기가 작고 연결 수가 많을수록 문제는 더 커진다. 순수 소프트웨어 경로는 바이트 단위 암호 연산뿐 아니라 패킷 단위 상태 관리까지 감당해야 하므로, 총 처리량보다 지연 시간의 흔들림이 먼저 나타나기도 한다. IPsec 오프로드는 이 반복 경로를 NIC 또는 DPU 내부의 전용 파이프라인으로 넘겨, 호스트는 정책과 세션 관리에 집중하고 데이터 변환은 하드웨어가 맡게 만든다.

이 그림은 왜 보안 처리가 CPU 병목으로 바뀌는지, 그리고 오프로드가 무엇을 떼어 가는지 보여 준다.

┌────────────────────────────────────────────────────────────────────────────┐
│        보안은 필요하지만, 패킷마다 CPU가 직접 봉인하면 선로 속도를 못 따라간다        │
├────────────────────────────────────────────────────────────────────────────┤
│ 소프트웨어 경로                                                           │
│ Application -> Kernel IPsec -> SA 조회 -> 암호화/인증 -> NIC -> Wire     │
│                 ▲            ▲               ▲                            │
│                 └─ 패킷마다 상태관리 + 헤더변환 + 암호연산                │
│                                                                            │
│ 오프로드 경로                                                              │
│ Application -> 정책 결정(Host) -> Offload NIC/DPU -> Wire                 │
│                        └─ 반복적인 데이터 평면 변환을 하드웨어가 전담      │
└────────────────────────────────────────────────────────────────────────────┘

IPsec 오프로드가 뜻하는 바는 "보안을 NIC에 전부 던진다"가 아니다. 정책 설치, IKE 협상, 키 교체, 예외 패킷 처리 같은 제어 평면은 여전히 호스트가 맡고, 가장 반복적이고 비싼 fast path만 하드웨어가 담당한다. 그래서 이 기술의 핵심은 기능 전체의 대체가 아니라 반복 경로의 전문화다.

📢 섹션 요약 비유: 매번 금고 비밀번호를 손으로 돌리던 경비원이 너무 바빠지자, 출입 허가 여부는 경비실이 판단하고 실제 잠금·봉인은 자동 금고 장치가 맡는 것과 같다. 규칙은 사람이 정하지만 반복 작업은 기계가 처리해야 전체 건물이 버틴다.

Ⅱ. 아키텍처 및 핵심 원리

IPsec 오프로드 아키텍처의 핵심은 "정책 결정"과 "패킷 변환"의 분리다. 호스트는 어떤 흐름이 어떤 SA를 써야 하는지 결정하고 키를 내려보내며, NIC/DPU는 실제 송수신 패킷에 대해 ESP 헤더 추가, 시퀀스 번호 증가, AES-GCM (Advanced Encryption Standard Galois/Counter Mode) 기반 암·복호화, 인증 태그 검증, anti-replay window 확인을 수행한다. 즉 하드웨어는 복잡한 정책 언어를 해석하기보다, 이미 정해진 보안 상태를 빠르게 반복 실행한다.

구성 요소	역할	설계 포인트
SA 테이블	키, 알고리즘, 터널 목적지, 시퀀스 상태를 저장한다.	동시 터널 수와 tenant 수를 감당할 수 있어야 한다.
암호화 엔진	AES-GCM 같은 대칭키 연산과 인증 태그 생성을 수행한다.	line rate와 알고리즘 호환성이 핵심이다.
패킷 변환기	ESP 캡슐화·역캡슐화, 헤더 재작성, 패딩 처리를 맡는다.	transport mode와 tunnel mode를 구분해야 한다.
재전송 방지 로직	시퀀스 번호를 관리하고 재생 공격을 차단한다.	보안 정확성과 out-of-order 허용 범위가 중요하다.
전송 큐 / 직접 메모리 접근 (Direct Memory Access, DMA) 경로	호스트 메모리와 NIC 사이에서 버퍼를 주고받는다.	큐 균형과 메모리 복사 최소화가 성능을 좌우한다.

이 그림은 송신과 수신에서 오프로드 파이프라인이 어떻게 작동하는지 요약한다.

┌────────────────────────────────────────────────────────────────────────────┐
│                   IPsec 오프로드 데이터 평면의 핵심 단계                   │
├────────────────────────────────────────────────────────────────────────────┤
│ 송신: Host Packet -> SA Lookup -> Seq Number -> ESP Add -> AES-GCM -> Send│
│ 수신: Receive Packet -> ESP Parse -> SA Lookup -> AES-GCM -> Replay Check │
│                                                 -> Plain Packet -> Host   │
│                                                                            │
│ Host CPU는 정책·IKE를, NIC/DPU는 반복적인 패킷 변환을 맡는다.             │
└────────────────────────────────────────────────────────────────────────────┘

여기서 자주 나뉘는 구현이 inline과 lookaside다. inline 오프로드는 NIC가 실제 전송 경로 한가운데서 패킷을 바로 보호·해제하므로 CPU 개입이 가장 적다. 반면 lookaside 오프로드는 호스트가 패킷 조립을 일부 맡고, 암호 연산만 별도 가속기에 맡기는 구조라 통합은 쉽지만 버퍼 왕복과 소프트웨어 잔여 비용이 더 남는다.

📢 섹션 요약 비유: inline은 톨게이트를 지나며 차가 자동 결제되는 방식이고, lookaside는 창구에 한 번 들러 결제만 맡기고 다시 차를 몰고 가는 방식이다. 둘 다 일을 덜어 주지만, 진짜 흐름이 매끄러운 쪽은 길 위에서 바로 처리하는 구조다.

Ⅲ. 비교 및 연결

IPsec 오프로드를 이해할 때 가장 많이 헷갈리는 비교 대상은 CPU 명령어 가속, lookaside 가속, inline 오프로드다. 세 방식은 모두 암호화를 빠르게 만들 수 있지만, CPU가 어디까지 패킷 경로를 계속 책임지느냐가 다르다. 따라서 "하드웨어 가속이 있다"는 말만으로는 실제 시스템 부담을 판단할 수 없다.

방식	CPU가 계속 맡는 부분	장점	한계
CPU 내 암호 명령어 가속	패킷 조립, SA 조회, 시퀀스 관리, 암호화 호출 모두 호스트가 수행	유연성이 높고 소프트웨어 수정이 쉽다	코어 사용량과 지터가 크게 남는다
Lookaside IPsec 가속	패킷 경로 상당 부분과 세션 상태 관리는 호스트가 유지	기존 스택에 붙이기 쉽다	버퍼 왕복과 일부 소프트웨어 비용이 남는다
Inline IPsec 오프로드	정책 설치와 제어 평면만 호스트가 유지	CPU 절감폭과 처리량이 가장 크다	지원 알고리즘·모드가 하드웨어 기능에 묶인다

또 다른 비교 대상은 전송 계층 보안 (Transport Layer Security, TLS) 오프로드다. TLS 오프로드가 애플리케이션 세션 종단과 인증서를 중심으로 동작한다면, IPsec 오프로드는 호스트 간 또는 게이트웨이 간 패킷 보호를 담당한다. 즉 둘은 경쟁 관계라기보다 보호 계층이 다른 병렬 수단이며, 최근 DPU는 이 둘을 함께 처리하는 방향으로 진화하고 있다.

결국 IPsec 오프로드는 일반적인 네트워크 인터페이스 카드 (Network Interface Card, NIC) 오프로딩이나 TOE (TCP/IP Offload Engine)보다 더 강한 보안 상태를 다뤄야 한다는 점에서 어렵다. 체크섬이나 세그먼트 분할처럼 stateless한 작업과 달리, IPsec은 키·시퀀스 번호·재전송 방지 윈도우를 정확히 유지해야 하므로 하드웨어 설계의 정합성이 더 중요하다.

📢 섹션 요약 비유: 단순 포장 자동화가 상자만 접는 기계라면, IPsec 오프로드는 고객별 자물쇠 번호까지 기억하는 금고 배송 시스템에 가깝다. 빠르기만 해서는 안 되고, 누구 물건인지 끝까지 틀리지 않아야 한다.

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

실무에서 가장 위험한 오판은 "NIC이 IPsec 지원"이라는 문구를 보고 모든 트래픽이 자동으로 하드웨어 처리된다고 가정하는 일이다. 실제 제품은 특정 알고리즘, 특정 모드, 특정 패킷 형태만 오프로드하고 나머지는 소프트웨어 slow path로 되돌리는 경우가 많다. 따라서 설계자는 평균 처리량뿐 아니라 fallback 비율, 예외 패킷 비중, SA churn까지 같이 봐야 한다.

예를 들어 데이터센터 게이트웨이는 대형 터널 수와 높은 대역폭이 중요하고, 원격 접속 VPN 장비는 작은 패킷이 많아 패킷당 오버헤드가 먼저 병목이 되기 쉽다. 전자는 line rate 유지가, 후자는 CPU 지터와 세션 밀도가 더 중요할 수 있다. 그래서 같은 "IPsec 가속"이라도 어떤 트래픽에 쓰느냐에 따라 평가 지표가 달라진다.

적용 판단 체크리스트

필요한 cipher와 mode가 하드웨어에서 실제 지원되는가?
동시 SA 수와 tenant 수가 NIC/DPU 테이블 한도 안에 들어오는가?
IKE 협상, 재키잉, 장애 시 재동기화 같은 제어 평면 부하를 호스트가 감당하는가?
터널 오버헤드 때문에 최대 전송 단위 (Maximum Transmission Unit, MTU) 문제가 생기지 않는가?
오프로드 miss, 인증 실패, replay drop을 관찰할 수 있는 telemetry가 준비되어 있는가?

피해야 할 안티패턴

지원하지 않는 알고리즘이나 모드를 선택해 결국 대부분의 패킷을 소프트웨어로 되돌리는 구성
하드웨어가 암호화만 빨라지면 제어 평면 병목도 사라질 것이라 착각하는 설계
MTU와 분편화를 무시해 터널은 안전하지만 실제 처리량은 오히려 떨어지는 배치
장애 분석 도구 없이 오프로드를 켜 놓고, slow path 전환 여부를 나중에야 알아차리는 운영
📢 섹션 요약 비유: 자동 금고차를 도입해 놓고 정작 열쇠 관리와 배송 목록 정리는 사람이 엉망으로 하면 소용이 없다. 빠른 금고차는 큰 도움을 주지만, 어떤 상자를 태울지 정하는 장부가 정확해야 진짜 효과가 난다.

Ⅴ. 기대효과 및 결론

IPsec 오프로드 가속기를 잘 적용하면 보안 트래픽이 더 이상 호스트 CPU의 세금처럼 느껴지지 않는다. 암호화로 잡아먹히던 코어를 애플리케이션과 가상화 관리에 돌릴 수 있고, 패킷 처리 지연도 더 일정해져 서비스 품질이 안정된다. 특히 전용 회로는 범용 CPU보다 와트당 처리량이 높아, 데이터센터 관점에서는 전력 효율 개선 효과도 크다.

물론 한계는 분명하다. 지원 알고리즘과 기능이 하드웨어에 묶이고, 디버깅 가시성은 소프트웨어보다 떨어지며, 제어 평면과 예외 패킷 처리는 여전히 호스트 책임이다. 앞으로는 IPsec·TLS·vSwitch·스토리지 보안까지 한 칩 안에서 묶어 처리하는 DPU가 늘어나면서, 오프로드의 단위가 "기능 하나"가 아니라 "데이터 경로 전체"로 넓어질 가능성이 크다.

결론적으로 IPsec 오프로드 가속기는 보안 정책은 호스트가 결정하되, 반복적인 패킷 보호는 전용 파이프라인에 맡기는 구조적 분업으로 기억하는 것이 가장 정확하다. 핵심은 암호화를 빠르게 하는 것보다, 보안 때문에 시스템 전체가 느려지지 않게 만드는 데 있다.

📢 섹션 요약 비유: 좋은 공항 보안은 승객 정보를 중앙에서 관리하되, 수하물 스캔은 전용 장비가 초고속으로 처리하는 구조다. 판정은 중앙이 하고, 반복 검사는 기계가 맡아야 공항 전체가 막히지 않는다.

📌 관련 개념 맵

개념	연결 포인트
보안 연관 (Security Association, SA)	어떤 키와 알고리즘으로 패킷을 보호할지 결정하는 IPsec의 핵심 상태다.
ESP (Encapsulating Security Payload)	실제 데이터 암호화와 무결성 보호가 적용되는 주된 패킷 형식이다.
인터넷 키 교환 (Internet Key Exchange, IKE)	오프로드가 빠르게 돌기 전에 필요한 키 합의와 재키잉을 담당한다.
AES-GCM	현대 IPsec 오프로드가 가장 자주 최적화하는 결합형 암호화·인증 방식이다.
Anti-Replay Window	중복 패킷과 재생 공격을 차단해 "빠르지만 틀린" 오프로드를 막는 안전장치다.
데이터 처리 장치 (Data Processing Unit, DPU)	IPsec을 포함한 네트워크·보안·가상화 오프로드를 통합하는 진화형 플랫폼이다.

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

소프트웨어 VPN 처리
        │
        ▼
CPU 내 암호 명령어 가속
        │
        ▼
Lookaside 보안 가속기
        │
        ▼
Inline IPsec Offload NIC
        │
        ▼
DPU 기반 통합 보안 데이터 평면

이 흐름은 보안 가속이 "CPU를 조금 돕는 단계"에서 출발해, 이제는 패킷 경로 전체를 전용 하드웨어가 책임지는 방향으로 진화하고 있음을 보여 준다.

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

비밀 편지를 보낼 때 내가 직접 자물쇠를 채우면 너무 오래 걸리지만, 옆의 자동 잠금 기계가 해 주면 훨씬 빨라요.
나는 누구에게 보낼지만 정하고, 기계는 편지를 단단히 잠가서 밖으로 보내 줘요.
그래서 편지도 안전하고, 나는 다른 중요한 일을 계속할 수 있답니다.