NGFW 하드웨어 오프로드

차세대 방화벽(NGFW) 하드웨어 오프로드 아키텍처 3대 유형(CPU중심 Lookaside·SoC중심 Lookaside·Inline SmartNIC/DPU), Fast/Slow/Exception 경로, Stateful 방화벽·NAT·ACL·QoS·터널(Tunnel)·IPSec 오프로드, 상용 NGFW 비교, Linux 커널 기반 NGFW 파이프라인(Pipeline), 세션 오프로드 결정 트리 종합 가이드

단계별 학습 로드맵

선수 지식 수준 가이드

핵심 용어 정리

NGFW HW 오프로드 개요

NGFW의 정의

차세대 방화벽(Next-Generation Firewall, NGFW)은 전통적인 L3/L4 패킷 필터링 방화벽에 다음 기능을 통합한 보안 장비입니다:

• Deep Packet Inspection (DPI) — L7 애플리케이션 프로토콜 분석
• Application Identification (App-ID) — 포트 번호가 아닌 실제 애플리케이션 식별
• Intrusion Prevention System (IPS) — 시그니처 기반 공격 탐지/차단
• SSL/TLS Inspection — 암호화(Encryption)된 트래픽 복호화(Decryption) 후 검사
• Stateful Session Tracking — conntrack 기반 연결 상태 추적
• URL Filtering / Threat Intelligence — 평판 기반 차단

이러한 기능은 패킷당 처리 비용을 크게 증가시키므로, 하드웨어 오프로드를 통해 검증이 완료된 세션의 후속 패킷을 CPU를 거치지 않고 직접 전달하는 것이 성능의 핵심입니다.

NGFW 세대별 진화

5세대의 핵심 차이점은 프로그래머블 오프로드입니다. 기존 ASIC은 벤더가 설계한 고정 파이프라인만 지원했지만, SmartNIC/DPU는 TC flower, eBPF, P4 등으로 오프로드 로직을 사용자가 정의할 수 있습니다.

NGFW 배치 모델

NGFW는 네트워크 내 위치와 동작 방식에 따라 여러 배치 모델이 있으며, 각 모델에서 HW offload의 적용 범위가 달라집니다:

전통 FW vs NGFW 비교

오프로드 필요성

NGFW에서 모든 패킷을 CPU에서 처리하면 다음과 같은 병목이 발생합니다:

• DPI 처리량: Suricata/Snort 단일 코어 처리량은 약 1~5 Gbps
• CPS (Connections Per Second): conntrack NEW + DPI 첫 분류까지 코어당 수만~수십만 CPS
• 메모리 대역폭(Bandwidth): 패킷 데이터 + conntrack 테이블 + DPI 시그니처 DB 접근

100Gbps 이상 인터페이스에서 NGFW를 운영하려면, ESTABLISHED 세션의 후속 패킷을 하드웨어에서 처리하고 CPU는 NEW 세션과 예외 상황에만 집중해야 합니다.

트래픽 프로파일과 오프로드 효과

실제 네트워크 트래픽에서 세션의 특성을 분석하면 오프로드의 효과를 정량적으로 이해할 수 있습니다:

핵심 인사이트: 세션 수로는 단수명 세션이 압도적이지만, 실제 트래픽 볼륨(바이트)의 80%는 소수의 장수명 세션이 차지합니다. 이 장수명 세션을 HW offload하면 전체 CPU 부하의 대부분을 해소할 수 있습니다.

NGFW 핵심 성능 지표

NGFW 성능을 평가할 때 반드시 구분해야 하는 핵심 메트릭입니다. 벤더 데이터시트는 대부분 "방화벽 처리량"만 강조하지만, 실제 NGFW 성능은 모든 보안 기능을 활성화한 상태에서 측정해야 합니다:

오프로드 아키텍처 3대 유형

NGFW 하드웨어 오프로드는 패킷이 처리되는 주체와 경로에 따라 크게 세 가지 아키텍처로 분류됩니다. 이 분류는 앞서 소개한 Fast/Slow/Exception 3계층 경로가 어떤 하드웨어에서, 어떤 방식으로 구현되는지를 결정하는 근본적인 설계 선택입니다.

• CPU중심 룩어사이드(CPU-Centric Lookaside) — CPU가 전체 패킷 처리 파이프라인을 주도하고, 특정 기능(암호화, 패턴 매칭 등)만 외장 가속기에 위임
• SoC중심 룩어사이드(SoC-Centric Lookaside) — 전용 네트워크 프로세서(NP) 또는 ASIC이 Fast Path를 전담하고, 예외 패킷만 CPU로 전달
• 인라인(Inline) — SmartNIC/DPU가 데이터 경로 자체에서 패킷을 처리하여 호스트 CPU를 완전히 우회

세 아키텍처는 상호 배타적이 아니며, 상용 NGFW는 기능별로 이를 혼합(Hybrid)하여 사용합니다. 예를 들어 Fortinet은 세션 오프로드에 SoC중심(NP7), SSL 복호화에 SoC중심(SP5), DPI에 CPU중심(CP9+CPU)을 동시에 적용합니다. 아래에서는 각 아키텍처의 전체 패킷 처리 관점에서의 동작 원리, 장단점, 적용 사례를 상세히 살펴봅니다.

CPU중심 룩어사이드 아키텍처

CPU중심 룩어사이드(CPU-Centric Lookaside) 아키텍처에서 범용 CPU(x86, ARM 서버)가 NGFW 파이프라인의 모든 단계를 직접 실행합니다. Netfilter 훅 체인, conntrack 상태 머신, nftables 규칙 평가, DPI 엔진(Suricata/nDPI) 호출이 모두 CPU에서 수행됩니다. 특정 연산이 CPU에 과도한 부하를 주는 경우에만 해당 작업을 PCIe 버스를 통해 외장 가속기(Lookaside 엔진)에 위임하고, 결과를 돌려받습니다.

동작 원리

1. 패킷 수신: NIC이 패킷을 수신하여 DMA로 호스트 메모리에 적재 → NAPI/인터럽트로 CPU에 통보
2. 전체 파이프라인 CPU 실행: Netfilter PREROUTING → conntrack → FORWARD(nftables ACL) → NFQUEUE(DPI) → POSTROUTING(NAT) 전 과정을 CPU가 순차 처리
3. Lookaside 위임(선택적): 암호화(QAT), 정규식 매칭(HyperScan FPGA), 압축(IAA) 등 CPU 집약적 연산만 가속기에 전송 → 비동기 완료 대기
4. 오프로드 판정 후 SW Fast Path: ESTABLISHED + ACCEPT 세션은 nf_flowtable에 등록하여 이후 패킷의 Netfilter 훅 체인을 건너뜀 (여전히 CPU에서 실행, 단 경로 단축)
5. 패킷 송신: CPU가 ip_output()을 호출하여 NIC TX 큐에 패킷 전달

핵심 특성

CPU중심 Lookaside의 패킷 흐름

아래 다이어그램은 CPU중심 아키텍처에서 새 세션(Slow Path)과 확립된 세션(SW Fast Path)의 처리 흐름을 보여줍니다. Lookaside 가속기는 파이프라인의 특정 단계에서만 호출됩니다.

CPU중심 아키텍처의 성능 프로파일

CPU중심 아키텍처에서의 Crypto Offload

CPU중심 아키텍처의 가장 일반적인 Lookaside 대상은 암호화 연산입니다. SSL Inspection이 활성화된 NGFW에서 CPU의 60~80%가 TLS 핸드셰이크(RSA/ECDHE)와 레코드 암·복호화(AES-GCM)에 소비되므로, 이를 PCIe 가속기(QAT, NITROX)에 위임하면 CPU 코어를 DPI에 집중할 수 있습니다.

CPU중심 아키텍처에서 QAT 가속기를 활용한 대표적인 NGFW crypto 파이프라인은 다음과 같습니다:

/* CPU중심 Lookaside NGFW crypto 파이프라인 */

[새 TLS 세션 - Slow Path]
패킷 수신 → conntrack NEW → nftables ACL ACCEPT
  → SSL MITM Proxy (nginx/haproxy)
    → TLS ClientHello 수신
    → QAT Lookaside: RSA-2048 서명 / ECDHE P-256 키 교환
      → CPU: -EINPROGRESS → 다른 패킷 처리 → QAT IRQ → 콜백
    → TLS 핸드셰이크 완료 → 대칭키 확보
    → setsockopt(SOL_TLS) → kTLS 활성화 (NIC inline 가능)
  → NFQUEUE → Suricata DPI (평문 검사)
  → Verdict ACCEPT → flowtable 등록

[확립된 TLS 세션 - Fast Path]
패킷 수신 → NIC Inline: kTLS 복호화 (AES-GCM)
  → flowtable bypass → NAT rewrite → NIC Inline: kTLS 재암호화 → TX
  → CPU 부하: 0%

SoC중심 룩어사이드 아키텍처

SoC중심 룩어사이드(SoC-Centric Lookaside) 아키텍처에서는 전용 네트워크 프로세서(NP) 또는 ASIC이 데이터 플레인의 Fast Path를 전담합니다. NP는 패킷 파싱, 세션 테이블 룩업, NAT rewrite, ACL 매칭, QoS 스케줄링을 하드웨어 파이프라인으로 와이어 속도에 가깝게 처리합니다. CPU는 컨트롤 플레인(정책 배포, 로깅, 관리)과 예외 패킷 처리(새 세션의 DPI, ALG, 정책 미매칭 패킷)만 담당합니다.

핵심 설계 원리는 "NP가 처리할 수 있는 패킷은 CPU에 전달하지 않는다"입니다. 새 세션의 첫 패킷만 CPU로 올라가고(Slow Path), CPU가 보안 검사를 완료하면 세션 정보를 NP의 하드웨어 세션 테이블에 프로그래밍합니다. 이후 해당 세션의 모든 패킷은 NP에서 직접 처리됩니다.

동작 원리

1. 패킷 수신: 물리 포트에서 패킷이 NP ASIC에 직접 도달 (호스트 메모리 DMA 없음)
2. NP 파이프라인 실행: 패킷 파서 → 세션 테이블 TCAM/Hash 룩업 → 매칭 시 NAT rewrite + ACL + QoS + 포워딩을 하드웨어에서 처리 → 즉시 TX
3. 세션 미스 → CPU 전달(Lookaside): 세션 테이블에 매칭되지 않는 패킷(새 세션, 예외)은 내부 버스를 통해 CPU로 전달
4. CPU에서 Slow Path 처리: conntrack NEW, nftables ACL, DPI/IPS 검사 수행
5. 세션 프로그래밍: CPU가 검사 결과(ACCEPT + 세션 정보)를 NP의 세션 테이블에 기록 → 이후 패킷은 NP에서 직접 처리

핵심 특성

SoC중심 Lookaside의 패킷 흐름

상용 NGFW의 SoC중심 구현 사례

SoC중심 아키텍처에서의 Crypto Offload

SoC중심 아키텍처에서 암호화 처리는 두 가지 경로로 나뉩니다. NP ASIC 내장 크립토 엔진이 Fast Path에서 IPSec을 인라인 처리하고, SoC 내부의 별도 크립토 코프로세서(CAAM, OCTEON CPT, SP5 등)가 SSL/TLS 복호화를 Lookaside로 처리합니다.

SoC중심 아키텍처의 핵심 장점은 NP와 크립토 엔진이 동일 SoC 다이 내에 있어 내부 버스(AXI/AMBA)로 직접 통신한다는 점입니다. PCIe를 거치지 않으므로 Lookaside 지연이 1~5μs로, CPU중심 아키텍처의 QAT(10~50μs) 대비 5~10배 빠릅니다. 이에 대한 상세 분석은 SoC중심 룩어사이드(암호화) 절을 참조하세요.

인라인(Inline) 오프로드 아키텍처

인라인(Inline) 아키텍처에서는 SmartNIC/DPU가 네트워크 데이터 경로 자체에 위치하여 패킷이 호스트 CPU를 거치지 않고 NIC 하드웨어에서 직접 처리됩니다. SoC중심 아키텍처의 NP와 유사하지만, 핵심 차이점은 표준 Linux 커널 인터페이스(TC flower, eSwitch, flowtable HW offload)를 통해 오프로드 규칙을 프로그래밍한다는 점입니다. 벤더 전용 API가 아닌 오픈 표준을 사용하므로 리눅스 기반 NGFW에서 가장 주목받는 아키텍처입니다.

인라인 아키텍처의 근본적인 설계 원리는 "확립된 세션의 패킷이 호스트 메모리를 전혀 건드리지 않는다"입니다. NIC의 eSwitch FDB에 설치된 TC flower 규칙이 5-tuple + conntrack 상태로 매칭하여, NAT rewrite, 터널 encap/decap, VLAN 처리를 NIC ASIC에서 직접 수행한 뒤 대상 포트로 전달합니다.

동작 원리

1. 패킷 수신: 이더넷 프레임이 NIC의 물리 포트에 도착
2. eSwitch FDB 룩업: NIC 내장 eSwitch가 FDB 테이블에서 5-tuple + ct_state 매칭 → HW 규칙 히트(Hit) 시 즉시 처리
3. HW Fast Path 처리: NAT rewrite, TTL 감소, 터널 encap/decap, VLAN push/pop을 NIC ASIC에서 실행 → 대상 포트 TX 큐로 직접 전달 (DMA-to-DMA, CPU 인터럽트 없음)
4. FDB 미스 → 호스트 CPU: 매칭되지 않는 패킷은 일반 NIC RX 큐를 통해 호스트 CPU로 DMA 전달 → Slow Path(Netfilter + DPI) 처리
5. 오프로드 설치: CPU에서 세션이 ESTABLISHED + ACCEPT로 확인되면 nf_flowtable이 TC flower 규칙을 생성하고 ndo_setup_tc()를 통해 NIC 드라이버에 전달 → eSwitch FDB에 HW 규칙 설치

핵심 특성

인라인 오프로드의 패킷 흐름

인라인 아키텍처의 Linux 커널 연동

인라인 아키텍처의 핵심 장점은 표준 Linux 커널 API를 통한 HW 오프로드입니다. NGFW 관리자는 일반적인 nftables/TC 명령으로 정책을 설정하면, 커널이 자동으로 NIC 하드웨어에 규칙을 설치합니다.

# 1. nftables에서 flowtable HW offload 정의
nft add table inet filter
nft add flowtable inet filter ft {
    hook ingress priority 0 \;
    devices = { enp1s0f0np0, enp1s0f1np0 } \;
    flags offload \;       # ← HW offload 핵심 플래그
}

# 2. ESTABLISHED 세션을 flowtable으로 전달
nft add chain inet filter forward { type filter hook forward priority 0 \; }
nft add rule inet filter forward ct state established,related flow add @ft

# 3. 커널이 자동으로 TC flower 규칙 생성 → NIC eSwitch FDB에 설치
# 확인: HW offload 규칙 조회
tc -s filter show dev enp1s0f0np0 ingress
# filter protocol ip pref 1 flower chain 0
#   ct_state +est+trk   ← HW에서 conntrack 상태 매칭
#   action mirred (Egress Redirect to device enp1s0f1np0)
#   in_hw in_hw_count 1  ← HW offload 확인

인라인 아키텍처에서의 Crypto Offload

인라인 아키텍처에서 SmartNIC/DPU는 세션 오프로드(flowtable)뿐 아니라 암호화도 인라인으로 처리합니다. 패킷이 NIC ASIC을 통과하는 과정에서 암·복호화가 와이어 속도로 수행되므로, 호스트 메모리에 암호화된 데이터가 전혀 도달하지 않습니다.

인라인 crypto의 핵심 제약은 AES-GCM 외 알고리즘 미지원과 SA/TLS context 수 제한(NIC 메모리 의존)입니다. 이 제약을 초과하는 세션은 자동으로 SW 폴백됩니다. 상세 알고리즘 매트릭스는 아키텍처별 알고리즘 지원 매트릭스를, NIC 벤더별 지원 현황은 전용 크립토 가속기 절을 참조하세요.

3대 아키텍처 종합 비교

아래 표는 세 아키텍처를 전체 NGFW 파이프라인 관점에서 비교합니다. 암호화에 특화된 비교는 암호화 오프로드 3종 비교를 참조하세요.

아키텍처 선택 가이드

데이터 플레인 아키텍처

Fast Path (HW + SW)

Fast Path는 이미 보안 검사가 완료된 세션의 후속 패킷을 최소 비용으로 전달하는 경로입니다. 두 가지 수준이 있습니다:

HW Fast Path (eSwitch FDB)

eSwitch의 switchdev 모드에서 TC flower 규칙으로 ct_state +est +trk 매칭 후 FDB(Forwarding Database) 룰을 NIC 하드웨어에 설치합니다. 패킷이 NIC에 도착하면 CPU를 거치지 않고 직접 전달됩니다.

HW Fast Path의 동작을 단계별로 보면:

1. 패킷 도착: 이더넷 프레임이 NIC의 RX 큐에 도달
2. eSwitch FDB lookup: NIC 내장 하드웨어가 5-tuple + ct_state로 FDB 테이블을 검색
3. 매칭 시 HW 처리: NAT rewrite (IP/Port/Checksum), TTL 감소, 터널 encap/decap, VLAN push/pop
4. 직접 TX: 처리된 패킷이 대상 포트의 TX 큐로 직접 전달 (DMA to DMA, CPU interrupt 없음)

• 수행: L2/L3/L4 헤더 매칭, NAT rewrite (SNAT/DNAT), VLAN push/pop, 터널 encap/decap (VXLAN/GRE/Geneve), conntrack 상태 확인
• 미수행: DPI 재검사, TCP window 검증, 시퀀스 번호 추적, ALG 프로토콜 파싱, IP 단편화(Fragmentation) 처리
• 처리량: NIC 라인레이트 (25/50/100/200Gbps)

SW Fast Path (nf_flowtable)

nf_flowtable은 커널 소프트웨어에서 conntrack을 bypass하고 직접 L3 forwarding을 수행합니다. HW offload가 불가능한 경우(예: NIC 미지원, 복잡한 NAT, 특정 터널)의 폴백 경로입니다.

SW Fast Path는 커널의 Netfilter ingress 훅(priority -10)에서 동작하여, 일반 Netfilter 체인(PREROUTING → FORWARD → POSTROUTING)을 완전히 건너뜁니다. 이를 통해 nftables 규칙 평가, conntrack 상세 추적, NFQUEUE 전달 등의 오버헤드를 제거합니다.

• 수행: conntrack bypass, L3 forwarding, NAT rewrite, TTL 감소, 통계 카운터
• 미수행: Netfilter 훅 체인, DPI, TCP 상태 머신 상세 추적
• 처리량: 코어당 약 10~40Gbps (패킷 크기 의존)

Fast Path 전환의 커널 내부 흐름

패킷이 Fast Path로 처리되는 과정을 커널 코드 수준에서 살펴보면:

/* net/netfilter/nf_flow_table_ip.c */
/* flowtable ingress 훅에서 호출되는 핵심 함수 */
static unsigned int
nf_flow_offload_ip_hook(void *priv, struct sk_buff *skb,
                        const struct nf_hook_state *state)
{
    struct flow_offload_tuple_rhash *tuplehash;
    struct nf_flowtable *flow_table = priv;
    struct flow_offload_tuple tuple = {};
    enum flow_offload_tuple_dir dir;
    struct flow_offload *flow;

    /* 1. skb에서 5-tuple 추출 */
    if (nf_flow_tuple_ip(skb, state->in, &tuple) < 0)
        return NF_ACCEPT;  /* 추출 실패 → Slow Path */

    /* 2. flowtable에서 lookup */
    tuplehash = flow_offload_lookup(flow_table, &tuple);
    if (!tuplehash)
        return NF_ACCEPT;  /* 미등록 플로우 → Slow Path */

    flow = container_of(tuplehash, struct flow_offload,
                        tuplehash[dir]);

    /* 3. TEARDOWN 상태면 Slow Path로 복귀 */
    if (flow_offload_stale_flow(flow))
        return NF_ACCEPT;

    /* 4. NAT rewrite 적용 */
    if (flow->flags & FLOW_OFFLOAD_SNAT)
        nf_flow_snat_ip(skb, thoff, ...);
    if (flow->flags & FLOW_OFFLOAD_DNAT)
        nf_flow_dnat_ip(skb, thoff, ...);

    /* 5. TTL 감소 + routing 적용 */
    ip_decrease_ttl(iph);
    skb_dst_set_noref(skb, &rt->dst);

    /* 6. 직접 전달 (Netfilter 훅 체인 건너뜀) */
    ip_output(state->net, state->sk, skb);
    return NF_STOLEN;  /* skb 소유권 가져감 → 훅 종료 */
}

flow_offload 구조체

/* include/net/netfilter/nf_flow_table.h */
struct flow_offload_tuple {
    union {
        struct in_addr   src_v4;   /* IPv4 소스 주소 */
        struct in6_addr  src_v6;   /* IPv6 소스 주소 */
    };
    union {
        struct in_addr   dst_v4;
        struct in6_addr  dst_v6;
    };
    struct {
        __be16  src;  /* 소스 포트 */
        __be16  dst;  /* 목적지 포트 */
    } port;
    u8      l3proto;    /* AF_INET / AF_INET6 */
    u8      l4proto;    /* IPPROTO_TCP / IPPROTO_UDP */
    struct dst_entry  *dst_cache; /* 라우팅 캐시 */
    int     iifidx;     /* ingress 인터페이스 인덱스 */
    int     oifidx;     /* egress 인터페이스 인덱스 */
};

struct flow_offload {
    struct flow_offload_tuple_rhash tuplehash[2]; /* [ORIGINAL] + [REPLY] */
    struct nf_conn  *ct;         /* 대응하는 conntrack 엔트리 */
    unsigned long    flags;      /* SNAT, DNAT, TEARDOWN 등 */
    u32              timeout;    /* GC 타임아웃 (jiffies) */
};

하나의 flow_offload는 양방향 플로우를 나타냅니다. tuplehash[0]은 ORIGINAL 방향, tuplehash[1]은 REPLY 방향의 5-tuple을 저장합니다. NAT가 적용된 경우 두 방향의 IP/포트가 다릅니다.

Slow Path (전체 검사)

새로운 연결의 첫 패킷(또는 아직 DPI 분류가 완료되지 않은 초기 패킷)은 전체 보안 파이프라인을 통과합니다. Slow Path는 NGFW의 보안 정밀도를 담당하며, 여기서의 결정이 세션의 나머지 수명 동안의 처리 방식을 결정합니다.

Slow Path에서의 패킷 처리 시간은 일반적으로 100us~5ms 범위입니다. DPI 엔진의 시그니처 수, 패킷 페이로드 크기, CPU 캐시(Cache) 히트율에 따라 달라집니다.

처리 순서:

1. Ingress ACL — nftables/TC filter 기반 정적 규칙 (IP/Port/Protocol 매칭)
2. conntrack — 연결 추적 테이블에 NEW 엔트리 생성 또는 기존 상태 갱신
3. NAT — SNAT/DNAT/MASQUERADE 주소 변환(Address Translation)
4. NFQUEUE — DPI 엔진으로 패킷 전달 (NFQUEUE & DPI 엔진 통합)
5. DPI / App-ID — 프로토콜 분류, 시그니처 매칭, 애플리케이션 식별
6. IPS — 시그니처 기반 공격 탐지
7. Verdict — ACCEPT/DROP/QUEUE 최종 판정

CPS 병목: Slow Path의 처리량은 주로 초당 새 연결(CPS)으로 측정됩니다. DPI 엔진에 따라 코어당 10K~100K CPS 범위이며, 이는 NGFW의 실질적 성능 한계를 결정합니다.

Slow Path 커널 호출 체인

/* Slow Path에서 새 패킷이 거치는 커널 함수 호출 순서 */

/* 1. PREROUTING: conntrack 입구 */
nf_conntrack_in()
  → resolve_normal_ct()
    → nf_conntrack_find_get()    /* 해시 테이블에서 기존 ct 검색 */
    → init_conntrack()            /* 미발견 시 NEW ct 생성 */
      → __nf_conntrack_alloc()   /* slab에서 nf_conn 할당 */
      → nf_ct_helper_find()      /* ALG 헬퍼 자동 할당 (SIP/FTP 등) */

/* 2. FORWARD: nftables 체인 평가 */
nft_do_chain()
  → nft_lookup_eval()            /* set/map 기반 ACL 매칭 */
  → nft_ct_eval()                /* ct state 조건 평가 */
  → nft_queue_eval()             /* NFQUEUE verdict → DPI 전달 */

/* 3. NFQUEUE: 유저스페이스 DPI 전달 */
nf_queue()
  → nf_queue_entry_get_refs()    /* 참조 카운터 증가 */
  → nfnetlink_queue_enqueue()    /* netlink 소켓으로 전달 */
  /* ... Suricata/nDPI가 패킷을 분석 ... */
  → nf_reinject()                /* verdict 반환 후 재주입 */

/* 4. POSTROUTING: NAT 적용 */
nf_nat_ipv4_out()
  → nf_nat_packet()
    → nf_nat_manip_pkt()         /* SNAT/DNAT 주소 변환 */

/* 5. 전송 */
ip_output()
  → ip_finish_output()
    → neigh_output()             /* L2 헤더 추가 후 NIC TX */

CPS 병목 분석

NGFW에서 Slow Path의 CPS가 전체 성능을 제한하는 원인을 세분화하면:

DPI가 전체 Slow Path 비용의 70~90%를 차지합니다. 따라서 DPI 완료 후 세션을 즉시 Fast Path로 전환하는 것이 핵심 최적화입니다.

Exception Path

이미 오프로드된 세션이라도 다음 경우에는 Fast Path에서 CPU로 복귀합니다:

• ALG 프로토콜 — FTP DATA, SIP RTP, H.323 등 동적 포트 할당이 필요한 프로토콜 (conntrack 헬퍼 & ALG)
• IP Fragment — 단편화된 패킷은 재조립 후 검사 필요
• ICMP Error — Destination Unreachable, TTL Exceeded 등 원래 세션의 상태 갱신 필요
• 정책 변경 재분류 — 관리자가 정책을 변경하면 기존 오프로드 플로우를 삭제하고 재평가
• TCP RST/FIN — 연결 종료 → flowtable GC → HW rule 삭제
• 바이트/패킷 임계치 — 보안 정책에 따라 주기적 샘플링을 위해 복귀

Exception Path 처리의 커널 내부

Exception Path의 핵심은 flow_offload_stale_flow() 검사와 HW trap 메커니즘입니다:

/* net/netfilter/nf_flow_table_core.c */
static bool flow_offload_stale_flow(struct flow_offload *flow)
{
    /* TEARDOWN 플래그: TCP FIN/RST 수신 시 설정 */
    if (flow->flags & FLOW_OFFLOAD_TEARDOWN)
        return true;

    /* DYING 플래그: GC에 의해 만료 대기 중 */
    if (flow->flags & FLOW_OFFLOAD_DYING)
        return true;

    /* conntrack이 삭제된 경우 */
    if (!nf_ct_is_confirmed(flow->ct))
        return true;

    return false;
}

/* GC 워커: 주기적으로 만료된 플로우 정리 */
static void nf_flow_offload_gc_step(struct nf_flowtable *flow_table)
{
    struct flow_offload_tuple_rhash *tuplehash;
    struct rhashtable_iter hti;

    rhashtable_walk_enter(&flow_table->rhashtable, &hti);
    rhashtable_walk_start(&hti);

    while ((tuplehash = rhashtable_walk_next(&hti))) {
        struct flow_offload *flow = ...;
        if (nf_flow_has_expired(flow) ||
            nf_ct_is_dying(flow->ct)) {
            /* HW rule 삭제 → 카운터 동기화 → ct 삭제 */
            flow_offload_teardown(flow);
            nf_flow_offload_del(flow_table, flow);
        }
    }
}

ALG 프로토콜의 Exception 처리

FTP, SIP, H.323 등 ALG(Application Level Gateway) 프로토콜은 제어 채널에서 동적으로 데이터 채널 포트를 협상합니다. 이 과정에서 conntrack helper가 페이로드를 파싱해야 하므로 오프로드가 불가능합니다.

NIC-Level 오프로드와 NGFW 파이프라인 상호작용

NIC 하드웨어에는 RSS, GRO, TSO, checksum offload 등 다양한 NIC-Level 오프로드 기능이 내장되어 있습니다. 이 기능들은 일반 네트워크 스택에서는 성능을 극대화하지만, NGFW 파이프라인과 결합하면 세션 친화성 깨짐, DPI 시그니처 미탐지, 바이트 카운터 불일치 등의 부작용을 일으킬 수 있습니다. 이 섹션에서는 각 NIC 오프로드 기능이 NGFW 파이프라인의 어느 단계와 상호작용하는지 분석하고, 최적 설정 방법을 제시합니다.

NIC 오프로드 기능과 NGFW 파이프라인 매핑

아래 표는 주요 NIC 오프로드 기능이 NGFW 파이프라인의 어떤 단계에 영향을 미치는지 정리한 것입니다. 영향의 성격은 긍정적(+), 부정적(-), 조건부(±)로 구분합니다.

RSS/aRFS/Flow Director와 NGFW 세션 친화성

NGFW에서 세션 친화성(Session Affinity)은 동일 세션의 모든 패킷이 동일 CPU 코어에서 처리되는 것을 의미합니다. 이것이 깨지면 conntrack 엔트리의 lock contention이 증가하고, DPI 엔진이 세션 상태를 공유해야 하므로 성능이 급격히 저하됩니다.

RSS 해시와 conntrack zone 정렬

RSS는 NIC 하드웨어가 수신 패킷의 L3/L4 헤더를 해시(Hash)하여 여러 RX 큐에 분배하는 기능입니다. 문제는 RSS 해시 함수가 conntrack의 양방향 세션 매핑을 인식하지 못한다는 점입니다.

예시: TCP 연결 (10.1.1.1:5000 → 192.168.1.1:80)

  순방향 RSS 해시: hash(10.1.1.1, 192.168.1.1, 5000, 80) = 큐 3 → CPU 3
  역방향 RSS 해시: hash(192.168.1.1, 10.1.1.1, 80, 5000) = 큐 7 → CPU 7

  결과: 동일 세션의 양방향 패킷이 서로 다른 CPU에서 처리됨
  → conntrack spinlock contention 발생
  → DPI 워커가 세션 상태를 cross-CPU로 참조해야 함

이 문제를 해결하려면 RSS 해시 키를 대칭 해시(Symmetric Hash)로 설정하여 양방향 패킷이 같은 큐로 분배되도록 해야 합니다.

# RSS 해시 키 확인
ethtool -x eth0

# 대칭(Symmetric) RSS 해시 설정 (Toeplitz 키를 대칭으로 변경)
# 드라이버에 따라 지원 여부가 다름 (mlx5, i40e 등 지원)
ethtool -X eth0 hfunc toeplitz

# RSS 해시 필드 설정: L3+L4 (src/dst IP + src/dst port)
ethtool -N eth0 rx-flow-hash tcp4 sdfn
ethtool -N eth0 rx-flow-hash udp4 sdfn

# 대칭 해시 지원 확인 (mlx5 드라이버)
ethtool --show-priv-flags eth0 | grep symmetric
# symmetric_rss가 있으면:
ethtool --set-priv-flags eth0 symmetric_rss on

aRFS: DPI 워커 CPU로 패킷 유도

aRFS(Accelerated Receive Flow Steering)는 커널이 소켓이 처리되는 CPU를 NIC에 알려주어, 해당 소켓의 패킷을 그 CPU의 RX 큐로 직접 유도하는 기능입니다. NGFW에서 NFQUEUE를 통해 DPI 엔진(Suricata, nDPI 등)이 특정 CPU에서 워커 스레드를 실행하고 있을 때, aRFS를 활용하면 해당 패킷이 DPI 워커가 실행 중인 CPU로 직접 전달됩니다.

# aRFS 활성화
echo 32768 > /proc/sys/net/core/rps_sock_flow_entries

# 각 RX 큐의 flow table 크기 설정
for rxq in /sys/class/net/eth0/queues/rx-*/rps_flow_cnt; do
    echo 4096 > "$rxq"
done

# ntuple 필터 활성화 (aRFS가 NIC에 룰을 설치하기 위해 필요)
ethtool -K eth0 ntuple on

# aRFS 동작 확인
cat /proc/net/softnet_stat
# 열 9: flow_limit_count, 열 10: rps_count

aRFS는 NFQUEUE 기반 DPI 파이프라인에서 특히 효과적입니다. DPI 워커가 nfq_set_queue_maxlen()으로 큐를 바인딩한 CPU와 패킷이 도착하는 CPU가 일치하면, cross-CPU IPI(Inter-Processor Interrupt) 없이 패킷이 DPI 워커로 전달됩니다.

Flow Director: Exception Path 전용 큐

Flow Director는 NIC 하드웨어가 특정 플로우 패턴(Flow Pattern)을 매칭하여 지정된 RX 큐로 스티어링(Steering)하는 기능입니다. NGFW에서는 Exception Path 트래픽(TCP RST, ICMP error, ALG 프로토콜)을 전용 큐로 분리하여 Fast Path 트래픽과의 간섭을 방지하는 데 활용합니다.

# Flow Director: TCP RST 패킷을 큐 0(Exception 전용)으로 스티어링
ethtool -N eth0 flow-type tcp4 action 0 loc 100

# ICMP error를 Exception 큐로
ethtool -N eth0 flow-type ip4 proto 1 action 0 loc 101

# FTP 제어 채널(포트 21)을 ALG 전용 큐로
ethtool -N eth0 flow-type tcp4 dst-port 21 action 1 loc 102

# SIP 시그널링(포트 5060)을 ALG 전용 큐로
ethtool -N eth0 flow-type udp4 dst-port 5060 action 1 loc 103

# 설치된 Flow Director 규칙 확인
ethtool -n eth0

GRO/GSO/LRO와 DPI 검사

패킷 병합(Coalescing) 오프로드는 인터럽트(Interrupt) 빈도를 줄이고 처리량을 높이는 데 효과적이지만, DPI 엔진의 패킷 경계 인식에 중대한 영향을 미칩니다.

GRO와 DPI 시그니처 매칭

GRO(Generic Receive Offload)는 연속된 TCP 세그먼트(Segment)를 하나의 큰 sk_buff로 병합하는 소프트웨어 오프로드입니다. GRO가 활성화되면 하나의 sk_buff에 최대 64KB의 페이로드가 담기며, 이는 DPI 엔진에 다음과 같은 영향을 줍니다:

• Suricata MPM(Multi-Pattern Matcher) — GRO 병합된 버퍼에서 시그니처 매칭 시 패턴이 두 원래 패킷의 경계에 걸쳐 있으면 정상적으로 탐지됩니다(오히려 유리). 그러나 per-packet 카운터 기반 시그니처(예: "3번째 패킷의 offset 0에서 매칭")는 오동작합니다.
• nDPI 프로토콜 탐지 — 프로토콜 핸드셰이크(Handshake)의 첫 몇 패킷을 개별적으로 분석해야 하는 경우, GRO로 병합되면 핸드셰이크 패턴 인식이 실패할 수 있습니다.
• IPS bypass 공격 — 공격자가 의도적으로 작은 세그먼트(Segment)를 전송하여 시그니처를 분산시키는 evasion 기법에 대해, GRO는 세그먼트를 재조합하므로 오히려 방어에 유리합니다.

/* net/core/dev.c - GRO 수신 경로 */
static int napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
{
    /* GRO 레이어가 동일 플로우의 skb를 병합 시도 */
    skb_gro_reset_offset(skb);
    /* ...
     * 병합 성공 시: skb->len이 원래 MSS의 배수로 증가
     * → NFQUEUE로 전달 시 단일 대형 skb로 전달됨
     * → DPI 엔진은 이를 단일 "논리 패킷"으로 처리
     */
    return napi_gro_complete(napi, skb);
}

LRO와 flowtable 비호환성

LRO(Large Receive Offload)는 GRO와 유사하지만 NIC 하드웨어에서 TCP 세그먼트를 병합합니다. LRO의 핵심 문제는 TCP 헤더를 재작성한다는 것입니다. LRO는 병합된 슈퍼 세그먼트에 대해 새로운 시퀀스 번호와 ACK 번호를 생성하는데, 이는 다음 문제를 일으킵니다:

• nf_flowtable 시퀀스 추적 실패 — flowtable은 conntrack의 TCP 시퀀스 윈도우 추적에 의존합니다. LRO가 시퀀스 번호를 변조하면 윈도우 검증이 실패하여 세션이 오프로드에서 제외됩니다.
• conntrack TCP strict 모드 충돌 — nf_conntrack_tcp_be_liberal=0(기본값)에서 LRO의 시퀀스 변조는 INVALID 상태를 유발합니다.
• 포워딩(Forwarding) 경로 문제 — LRO는 로컬 수신(Local Receive) 전용으로 설계되었으며, 포워딩 경로에서 사용하면 원래 패킷 구조를 복원할 수 없습니다.

# flowtable 사용 시 LRO 반드시 비활성화
ethtool -K eth0 lro off

# 확인
ethtool -k eth0 | grep large-receive-offload
# large-receive-offload: off

/* net/netfilter/nf_flow_table_core.c */
static bool nf_flow_offload_check(struct nf_flowtable *flowtable,
                                   struct flow_offload *flow)
{
    /*
     * LRO가 활성화된 인터페이스에서는 TCP 시퀀스 추적이
     * 불안정하므로 flowtable 오프로드가 실패할 수 있음.
     * 커널은 dev->features에서 NETIF_F_LRO 플래그를 확인하고
     * 포워딩 경로에서 자동으로 LRO를 비활성화함.
     * (dev_disable_lro() in net/core/dev.c)
     */
    ...
}

GSO와 TC flower 액션 재분할

GSO(Generic Segmentation Offload)는 TX 경로에서 커널이 큰 세그먼트를 MSS 단위로 분할하는 소프트웨어 오프로드입니다. TC flower 액션이 적용된 후 GSO 재분할이 필요한 경우, 다음과 같은 상호작용이 발생합니다:

TX 경로에서 TC flower + GSO 상호작용:

  1. 커널이 64KB GSO 세그먼트 생성
  2. TC egress에서 flower 규칙 매칭 → NAT rewrite 액션 실행
  3. NAT rewrite 후 체크섬 무효화
  4. GSO가 MSS 단위로 분할 (예: 1460B × 44 세그먼트)
  5. 각 분할 세그먼트에 대해 체크섬 재계산 필요

  → HW TSO가 활성화되면 단계 4~5를 NIC가 처리
  → HW TSO가 비활성화되면 CPU가 44회 분할 + 체크섬 계산

eSwitch HW offload에서는 TC flower 매칭, NAT rewrite, GSO 분할이 단일 하드웨어 파이프라인으로 처리되므로 이 문제가 발생하지 않습니다. 그러나 SW 경로에서는 TC flower 액션과 GSO의 순서가 성능에 영향을 줍니다.

TSO/Checksum 오프로드와 TC flower 카운터

TX 경로의 오프로드 기능은 NGFW의 트래픽 통계와 과금(Accounting)에 직접적인 영향을 미칩니다.

TSO와 바이트 카운터 불일치

TSO(TCP Segmentation Offload)가 활성화되면 커널은 최대 64KB의 슈퍼 세그먼트를 NIC로 전달하고, NIC 하드웨어가 이를 MSS 단위로 분할합니다. 문제는 TC flower의 패킷/바이트 카운터가 분할 전의 슈퍼 세그먼트를 기준으로 계산된다는 것입니다.

TSO가 TC flower 카운터에 미치는 영향:

  실제 전송: 44 × 1460B = 64,240 바이트 (44 패킷)
  TC flower 카운터: 1 패킷, 64,240 바이트

  → 패킷 카운터가 실제보다 1/44로 축소
  → PPS(Packets Per Second) 기반 QoS 정책이 부정확해짐
  → conntrack byte accounting과 TC flower 카운터가 불일치

# TC flower 규칙의 카운터 확인
tc -s filter show dev eth0 ingress

# conntrack 바이트 카운터 비교
conntrack -L -o extended | grep "10.1.1.1"

# 불일치 확인 예시:
# TC flower: packets 1523, bytes 98,234,880
# conntrack: packets 67,012, bytes 98,234,880
# → 바이트는 일치하지만 패킷 수가 44배 차이

Checksum 오프로드와 NAT 재계산

NAT 변환 후에는 IP 헤더와 TCP/UDP 체크섬을 재계산해야 합니다. 체크섬 오프로드의 SW/HW 처리 방식에 따라 NGFW 파이프라인의 동작이 달라집니다:

/* net/netfilter/nf_nat_core.c - NAT 후 체크섬 처리 */
static void nf_nat_csum_recalc(struct sk_buff *skb,
                                u8 proto, __be32 oldip, __be32 newip)
{
    /*
     * skb->ip_summed == CHECKSUM_PARTIAL이면
     * 체크섬의 pseudo-header 부분만 업데이트하고
     * 나머지는 NIC HW가 최종 계산 (TX checksum offload)
     *
     * skb->ip_summed == CHECKSUM_NONE이면
     * 전체 체크섬을 SW에서 재계산
     */
    inet_proto_csum_replace4(&tcp_hdr(skb)->check, skb,
                             oldip, newip, true);
}

conntrack의 바이트 어카운팅(Byte Accounting)과 관련하여, NAT 변환 전후의 패킷 크기가 변하지 않으므로(IP/포트 필드만 변경) 바이트 카운터에는 영향이 없습니다. 다만 NAT helper(ALG)가 페이로드를 수정하는 경우(FTP PORT 명령의 IP 주소 변경 등)에는 페이로드 크기가 변할 수 있으며, 이때 체크섬과 시퀀스 번호 조정이 모두 필요합니다.

NGFW 최적 NIC 오프로드 설정

NGFW의 동작 모드에 따라 NIC 오프로드 설정이 달라져야 합니다. 아래는 두 가지 대표적인 모드별 권장 설정입니다.

DPI 모드 vs 순수 포워딩 모드 비교

자동화 설정 스크립트

#!/bin/bash
# NGFW NIC 오프로드 최적 설정 스크립트
# 사용법: ./ngfw-nic-offload.sh <인터페이스> <dpi|forward>

IFACE="${1:?Usage: $0  }"
MODE="${2:?Usage: $0  }"

echo "=== NGFW NIC Offload 설정: ${IFACE} (${MODE} 모드) ==="

# 공통 설정 (두 모드 공유)
ethtool -K "$IFACE" lro off          # flowtable 호환을 위해 항상 OFF
ethtool -K "$IFACE" tx on            # TX checksum offload ON
ethtool -K "$IFACE" rx on            # RX checksum offload ON
ethtool -K "$IFACE" tso on           # TCP Segmentation Offload ON
ethtool -K "$IFACE" gso on           # Generic Segmentation Offload ON

# 대칭 RSS 해시 (드라이버 지원 시)
ethtool --set-priv-flags "$IFACE" symmetric_rss on 2>/dev/null \
    && echo "[OK] symmetric RSS 활성화" \
    || echo "[SKIP] symmetric RSS 미지원"

# RSS 해시 필드: L3+L4 (양방향 세션 친화성)
ethtool -N "$IFACE" rx-flow-hash tcp4 sdfn 2>/dev/null
ethtool -N "$IFACE" rx-flow-hash udp4 sdfn 2>/dev/null
ethtool -N "$IFACE" rx-flow-hash tcp6 sdfn 2>/dev/null
ethtool -N "$IFACE" rx-flow-hash udp6 sdfn 2>/dev/null

case "$MODE" in
  dpi)
    echo "--- DPI 모드 (Suricata/IPS 연동) ---"
    ethtool -K "$IFACE" gro off        # DPI 시그니처 정확도 우선
    ethtool -K "$IFACE" ntuple on      # aRFS/Flow Director 필요
    
    # aRFS 활성화
    echo 32768 > /proc/sys/net/core/rps_sock_flow_entries
    for rxq in /sys/class/net/"$IFACE"/queues/rx-*/rps_flow_cnt; do
        echo 4096 > "$rxq"
    done
    
    # Flow Director: Exception 패킷을 큐 0으로 분리
    ethtool -N "$IFACE" flow-type tcp4 action 0 loc 100 2>/dev/null
    ethtool -N "$IFACE" flow-type ip4 proto 1 action 0 loc 101 2>/dev/null
    
    echo "[DPI] GRO=off, aRFS=on, FlowDir=on"
    ;;
  forward)
    echo "--- 순수 포워딩 모드 (ACL + NAT) ---"
    ethtool -K "$IFACE" gro on         # 처리량 최적화
    
    echo "[FORWARD] GRO=on, aRFS=off, FlowDir=off"
    ;;
  *)
    echo "ERROR: 모드는 'dpi' 또는 'forward'만 지원합니다."
    exit 1
    ;;
esac

echo "=== 최종 오프로드 상태 ==="
ethtool -k "$IFACE" | grep -E "rx-checksumming|tx-checksumming|tcp-segmentation|generic-segmentation|generic-receive|large-receive|ntuple"

세션 오프로드 생명주기

첫 패킷 처리

TCP SYN 또는 첫 UDP 패킷이 도착하면 다음 과정을 거칩니다:

1. conntrack NEW — nf_conntrack_in()에서 새 conntrack 엔트리 생성
2. 전체 Netfilter 훅 — PREROUTING → FORWARD → POSTROUTING 체인의 모든 규칙 평가
3. NFQUEUE 전달 — DPI 엔진(Suricata, nDPI 등)이 패킷을 수신하여 프로토콜 분석 시작
4. App-ID 분류 — 첫 패킷만으로 부족하면 DPI 엔진이 추가 패킷 요청 (보통 3~10패킷)
5. Verdict 반환 — DPI 엔진이 ACCEPT 또는 DROP verdict를 반환

이 단계에서 오프로드는 발생하지 않습니다. 모든 검사가 완료될 때까지 Slow Path에 머뭅니다.

첫 패킷 conntrack 처리 상세

/* net/netfilter/nf_conntrack_core.c - 새 연결 생성 */
static struct nf_conntrack_tuple_hash *
init_conntrack(struct net *net, struct nf_conn *tmpl,
               const struct nf_conntrack_tuple *tuple,
               struct sk_buff *skb)
{
    struct nf_conn *ct;

    /* conntrack_max 초과 시 early drop (LRU) */
    if (nf_conntrack_max &&
        atomic_read(&net->ct.count) >= nf_conntrack_max) {
        if (!early_drop(net, hash))
            return ERR_PTR(-ENOMEM);  /* DROP: 테이블 가득 참 */
    }

    /* nf_conn 구조체 할당 (slab 캐시) */
    ct = __nf_conntrack_alloc(net, zone, tuple, ...);

    /* L4 프로토콜별 초기 상태 설정 */
    /* TCP: SYN_SENT, UDP: UNREPLIED */
    l4proto->new(ct, skb, dataoff);

    /* ALG helper 자동 할당 (포트 기반) */
    if (net->ct.sysctl_auto_assign_helper)
        nf_ct_helper_find(ct, tuple);

    /* unconfirmed list에 추가 (아직 해시에 삽입하지 않음) */
    /* POSTROUTING에서 confirm되면 해시 테이블에 삽입 */
    nf_ct_add_to_unconfirmed_list(ct);

    return &ct->tuplehash[IP_CT_DIR_ORIGINAL];
}

DPI 엔진의 패킷 분류 과정

NFQUEUE를 통해 유저스페이스 DPI 엔진(Suricata/nDPI)에 전달된 패킷의 분류 과정입니다:

일반적으로 3~10개 패킷이면 App-ID 분류가 완료됩니다. TLS 1.3에서 Encrypted Client Hello(ECH)가 사용되면 SNI가 암호화되어 더 많은 패킷이 필요하거나, SSL 복호화 없이는 분류가 불가능합니다.

ESTABLISHED 전환

TCP 3-way handshake가 완료되면 conntrack 상태가 ESTABLISHED로 전환됩니다. 이 시점에서 오프로드 여부를 결정합니다.

오프로드 결정 기준 4가지:

1. DPI 분류 완료 — App-ID가 결정되고 ALLOW verdict가 나왔는가?
2. ALG 프로토콜 아닌가 — FTP/SIP/H.323 등 동적 포트 할당이 필요한 프로토콜은 오프로드 불가
3. IP 단편화 아닌가 — 단편화된 패킷 스트림은 오프로드 불가
4. HW 지원 여부 — NIC/SmartNIC이 해당 플로우의 오프로드를 지원하는가? (터널 타입, NAT 유형 등)

오프로드 등록 커널 코드

nftables에서 flow add @ft가 실행되면 내부적으로 다음이 호출됩니다:

/* net/netfilter/nft_flow_offload.c */
static void nft_flow_offload_eval(const struct nft_expr *expr,
                                   struct nft_regs *regs,
                                   const struct nft_pktinfo *pkt)
{
    struct nf_conn *ct;
    enum ip_conntrack_info ctinfo;

    ct = nf_ct_get(pkt->skb, &ctinfo);

    /* 오프로드 가능 조건 확인 */
    if (nf_ct_is_dying(ct))
        goto err;
    if (nf_ct_helper(ct))        /* ALG helper 있으면 불가 */
        goto err;

    /* flow_offload 구조체 생성 */
    struct flow_offload *flow = flow_offload_alloc(ct);

    /* 라우팅 캐시 설정 */
    flow_offload_route_init(flow, &route);

    /* flowtable 해시에 등록 */
    flow_offload_add(&ft->ft, flow);

    /* HW offload 플래그가 있으면 NIC에도 등록 */
    if (ft->ft.flags & NF_FLOWTABLE_HW_OFFLOAD)
        nf_flow_offload_hw_add(net, flow, ct);
        /* → TC flower ct 규칙 → NIC eSwitch FDB 삽입 */
}

nf_flow_offload_hw_add()는 내부적으로 TC flower API를 호출하여 eSwitch에 FDB 규칙을 삽입합니다. 이 과정은 워크큐에서 비동기적으로 수행되므로, HW 규칙 설치까지 수 밀리초의 지연이 발생할 수 있습니다. 이 사이에 도착하는 패킷은 SW flowtable에서 처리됩니다.

오프로드 결정 트리

오프로드 해제

오프로드된 세션은 다음 상황에서 해제됩니다:

1. TCP FIN/RST — 연결 종료 신호가 감지되면 flowtable에서 DYING 상태로 전환
2. GC 타이머(Timer) — nf_flow_offload_gc_step()이 주기적으로 만료된 엔트리 정리
3. HW rule 삭제 — nf_flow_offload_hw_del()이 eSwitch FDB 규칙을 제거
4. conntrack 삭제 — 관련 conntrack 엔트리도 정리하여 리소스 해제

/* flowtable 오프로드 해제 흐름 */
TCP FIN/RST 수신
  → flow_offload_teardown()       /* FLOW_OFFLOAD_TEARDOWN 플래그 설정 */
    → nf_flow_offload_gc_step()   /* GC 워크큐가 DYING 플로우 정리 */
      → nf_flow_table_offload_del() /* HW rule 삭제 (TC flower del) */
        → nf_ct_delete()          /* conntrack 엔트리 삭제 */

GC 메커니즘 상세

flowtable의 Garbage Collection은 두 가지 메커니즘으로 동작합니다:

HW 카운터 동기화: HW offload된 플로우가 삭제될 때, NIC에서 처리된 패킷/바이트 카운터를 SW 카운터에 동기화합니다. 이를 통해 conntrack -L이나 nft list counter에서 정확한 통계를 확인할 수 있습니다.

/* HW 카운터 동기화 (net/netfilter/nf_flow_table_offload.c) */
static void nf_flow_offload_stats(struct flow_offload *flow,
                                    struct flow_stats *stats)
{
    struct nf_conn_acct *acct = nf_conn_acct_find(flow->ct);

    /* HW에서 읽어온 패킷/바이트 카운터를 conntrack에 반영 */
    atomic64_add(stats[0].pkts, &acct->counter[IP_CT_DIR_ORIGINAL].packets);
    atomic64_add(stats[0].bytes, &acct->counter[IP_CT_DIR_ORIGINAL].bytes);
    atomic64_add(stats[1].pkts, &acct->counter[IP_CT_DIR_REPLY].packets);
    atomic64_add(stats[1].bytes, &acct->counter[IP_CT_DIR_REPLY].bytes);

    /* 타임스탬프 갱신 → GC 타임아웃 리셋 */
    flow->timeout = nf_flowtable_time_stamp + flow_offload_get_timeout(flow);
}

Stateful 방화벽 오프로드

ACL HW 오프로드

TC flower를 사용하여 ct_state 매칭과 함께 ACL 규칙을 eSwitch에 설치할 수 있습니다. 이를 통해 conntrack 상태 기반 방화벽 규칙이 하드웨어에서 직접 평가됩니다.

# eSwitch switchdev 모드에서 TC flower ct 규칙 예시
# 1. ct zone 설정 및 conntrack 추적 시작
tc filter add dev eth0_rep0 ingress prio 1 \
  protocol ip flower \
  ct_state -trk \
  action ct zone 1

# 2. ESTABLISHED+TRACKED 세션 → HW offload forward
tc filter add dev eth0_rep0 ingress prio 2 \
  protocol ip flower \
  ct_state +trk+est \
  action ct zone 1 \
  action mirred egress redirect dev eth1_rep0

# 3. NEW+TRACKED 세션 → CPU (Slow Path)
tc filter add dev eth0_rep0 ingress prio 3 \
  protocol ip flower \
  ct_state +trk+new \
  action pass # CPU로 전달하여 전체 검사

# 4. INVALID → DROP
tc filter add dev eth0_rep0 ingress prio 4 \
  protocol ip flower \
  ct_state +trk+inv \
  action drop

conntrack HW 오프로드

NF_FLOWTABLE_HW_OFFLOAD 플래그가 활성화되면, flowtable에 등록된 플로우가 NIC 하드웨어의 conntrack 테이블에도 설치됩니다.

# flowtable HW offload 활성화
nft add flowtable inet filter ft \
  { hook ingress priority 0\; devices = { eth0, eth1 }\; \
    flags offload\; }

# forward chain에서 established 세션을 flowtable으로 등록
nft add rule inet filter forward \
  ct state established \
  flow add @ft

# 오프로드 상태 실시간 확인
conntrack -L --status OFFLOAD
# 출력 예:
# tcp  6 300 ESTABLISHED src=10.0.0.1 dst=192.168.1.1
#   sport=45678 dport=443 [OFFLOAD] mark=0 use=2

HW offload 내부 메커니즘

flowtable HW offload는 다음 과정으로 NIC에 규칙을 설치합니다:

/* HW offload 규칙 설치 흐름 */
nf_flow_offload_hw_add()
  → nf_flow_offload_tuple()
    → flow_offload_mangle()      /* NAT rewrite 액션 구성 */
    → flow_action_entry_set()    /* TC flow_action 구조체 채움 */
  → nf_flow_table_offload_add()
    → flow_block_cb()            /* NIC 드라이버 콜백 호출 */
      → mlx5e_tc_offload_fdb_rules()  /* mlx5: FDB rule 삽입 */
      → ice_tc_flower_action()         /* ice: TC flower 규칙 */

NIC 드라이버는 FLOW_BLOCK_BIND/FLOW_BLOCK_UNBIND 이벤트를 통해 flowtable과 연결됩니다. 드라이버가 지원하지 않는 플로우 타입(예: 특수 NAT, 미지원 터널)에 대해서는 -EOPNOTSUPP를 반환하고, 이 경우 SW flowtable에서만 처리됩니다.

HW conntrack의 한계:

• TCP window 검증 — HW에서는 TCP 윈도우/시퀀스 번호의 유효성을 검증하지 않습니다. 이를 악용한 공격(out-of-window injection)에 대해서는 주기적 샘플링으로 대응합니다.
• conntrack 테이블 크기 — NIC HW의 flow table 크기가 제한적 (수만~수십만 엔트리). 초과 시 SW flowtable로 폴백합니다.
• NAT 변환 복잡도 — CGNAT(Many-to-one NAT)이나 복잡한 NAT 매핑은 HW에서 지원하지 않을 수 있습니다.
• 프로토콜 제한 — TCP와 UDP만 HW offload 가능. ICMP, GRE, SCTP 등은 SW 처리
• IPv6 지원 — NIC에 따라 IPv6 CT offload 미지원 가능. 지원 여부는 ethtool -k에서 확인

conntrack HW offload 호환성 매트릭스

NAT 오프로드

SNAT/DNAT 주소 변환은 flowtable과 eSwitch 모두에서 오프로드할 수 있습니다. (NAT 아키텍처 참고)

NAT 오프로드의 커널 구현

flowtable NAT offload는 conntrack의 NAT 정보를 flow_offload 구조체에 복사하여, 이후 패킷을 conntrack 없이 직접 변환합니다:

/* net/netfilter/nf_flow_table_ip.c - NAT 오프로드 적용 */
static int nf_flow_nat_ip(const struct flow_offload *flow,
                           struct sk_buff *skb,
                           unsigned int thoff,
                           enum flow_offload_tuple_dir dir)
{
    struct iphdr *iph = ip_hdr(skb);

    /* SNAT: 소스 IP/포트 교체 */
    if (flow->flags & FLOW_OFFLOAD_SNAT) {
        /* ORIGINAL 방향: src → NAT 주소로 변경 */
        /* REPLY 방향: dst → 원래 주소로 복원 */
        nf_flow_snat_port(skb, thoff,
            flow->tuplehash[!dir].tuple.src_v4.s_addr,
            flow->tuplehash[!dir].tuple.port.src);
        /* IP 체크섬 + L4 체크섬 재계산 */
        csum_replace4(&iph->check, iph->saddr, new_addr);
    }

    /* DNAT: 목적지 IP/포트 교체 (위와 유사) */
    if (flow->flags & FLOW_OFFLOAD_DNAT)
        nf_flow_dnat_port(skb, thoff, ...);

    return 0;
}

CGNAT 대규모 NAT 시나리오

통신사(ISP) 환경의 CGNAT(Carrier-Grade NAT)에서는 수만 개의 내부 IP를 소수의 공인 IP로 변환합니다. 이 경우:

• 포트 풀 관리: 각 공인 IP당 ~64K 포트를 내부 IP에 분배. 포트 소진 시 새 연결 불가
• HW NAT의 한계: 일부 NIC은 한정된 NAT 매핑 테이블만 지원 (수만 엔트리). 초과 시 SW 폴백
• Deterministic NAT: 포트 범위를 사전 할당하여 로깅 부하 감소. nft add map으로 구현 가능

# CGNAT nftables 설정 예시
table ip cgnat {
    chain postrouting {
        type nat hook postrouting priority 100; policy accept;

        # 내부 대역별 공인 IP 분배 (Deterministic NAT)
        ip saddr 100.64.0.0/24 snat to 203.0.113.1:1024-32767
        ip saddr 100.64.1.0/24 snat to 203.0.113.1:32768-65535
        ip saddr 100.64.2.0/24 snat to 203.0.113.2:1024-32767

        # 폴백: 나머지 → 공인 IP 풀에서 동적 할당
        ip saddr 100.64.0.0/10 snat to 203.0.113.1-203.0.113.10
    }
}

# CGNAT 세션도 flowtable 오프로드 적용
nft add rule ip cgnat forward \
  ct state established flow add @ft

QoS/터널/IPSec 오프로드

DSCP/QoS 오프로드

TC flower로 DSCP 필드를 매칭하고 QoS 큐에 매핑하는 규칙을 eSwitch에 설치할 수 있습니다.

# DSCP EF (46) → TC 큐 0 (높은 우선순위)
tc filter add dev eth0_rep0 ingress prio 1 \
  protocol ip flower \
  ip_tos 0xb8/0xfc \
  action skbedit priority 0

# DSCP AF11 (10) → TC 큐 2 (낮은 우선순위)
tc filter add dev eth0_rep0 ingress prio 2 \
  protocol ip flower \
  ip_tos 0x28/0xfc \
  action skbedit priority 2

DSCP/QoS 매핑 상세

NGFW에서 QoS는 보안 정책과 연계됩니다. DPI 결과(App-ID)에 따라 DSCP 값을 재마킹하고, HW QoS 큐에 매핑하는 패턴입니다:

# NGFW에서 DPI 결과 기반 DSCP 재마킹
# nftables에서 App-ID → DSCP 매핑 (DPI 엔진이 ct mark에 App-ID 기록)
table inet qos_mark {
    map app_dscp {
        type mark : verdict
        elements = {
            0x0001 : accept,    # VoIP → DSCP EF (DPI에서 이미 마킹)
            0x0002 : accept,    # Video → DSCP AF41
            0x0003 : accept,    # Web → DSCP AF11
        }
    }

    chain forward {
        type filter hook forward priority 50; policy accept;
        # DPI 엔진이 ct mark에 기록한 App-ID → DSCP 재마킹
        ct mark 0x0001 ip dscp set ef
        ct mark 0x0002 ip dscp set af41
        ct mark 0x0003 ip dscp set af11
    }
}

# HW QoS 큐 설정 (TC MQPRIO)
tc qdisc add dev eth0 root mqprio \
  num_tc 4 map 3 3 2 2 1 1 0 0 0 0 0 0 0 0 0 0 \
  queues 1@0 1@1 2@2 4@4 hw 1

터널 오프로드

NGFW에서 터널은 두 가지 역할을 합니다: 사이트 간 VPN과 오버레이(Overlay) 네트워크. eSwitch는 다음 터널 타입의 encap/decap을 하드웨어에서 수행합니다:

• VXLAN — L2 over UDP 캡슐화(Encapsulation), 가장 널리 지원
• GRE — IP over IP 캡슐화 (GRE 프로토콜)
• Geneve — 유연한 TLV 옵션을 지원하는 현대적 터널

터널 + NGFW 오프로드 결합

터널 decap → 내부 패킷 DPI → 오프로드의 전체 흐름을 TC flower로 구성합니다:

# VXLAN 터널 디바이스 생성
ip link add vxlan0 type vxlan id 100 \
  local 10.0.0.1 dport 4789 nolearning external

# eSwitch에서 VXLAN decap + conntrack + forward 규칙
# chain 0: 외부 헤더로 VXLAN 매칭 → decap
tc filter add dev eth0_rep0 ingress chain 0 prio 1 \
  protocol ip flower \
  enc_dst_ip 10.0.0.1 enc_dst_port 4789 enc_key_id 100 \
  action tunnel_key unset pipe \
  action goto chain 1

# chain 1: decap된 내부 패킷에 conntrack 적용
tc filter add dev eth0_rep0 ingress chain 1 prio 1 \
  protocol ip flower ct_state -trk \
  action ct zone 1 pipe \
  action goto chain 2

# chain 2: EST → HW forward, NEW → CPU
tc filter add dev eth0_rep0 ingress chain 2 prio 1 \
  protocol ip flower ct_state +trk+est \
  action ct zone 1 nat pipe \
  action mirred egress redirect dev eth1_rep0

tc filter add dev eth0_rep0 ingress chain 2 prio 2 \
  protocol ip flower ct_state +trk+new \
  action pass # CPU → nftables → NFQUEUE → DPI

IPSec 인라인 크립토 오프로드

IPSec & xfrm의 HW 오프로드를 NGFW 파이프라인에 통합하면, 암호화/복호화를 NIC에서 수행하고 평문 패킷만 DPI 엔진에 전달할 수 있습니다.

# IPSec crypto offload 활성화 (xfrm)
ip xfrm state add src 10.0.0.1 dst 10.0.0.2 \
  proto esp spi 0x1001 reqid 1 mode tunnel \
  enc 'aes' 0x$(head -c 16 /dev/urandom | xxd -p) \
  offload dev eth0 dir out

IPSec 오프로드 모드 비교

NGFW와의 통합 포인트: IPSec 수신 시 NIC이 복호화를 수행하고, 평문(decrypted) 패킷이 커널에 전달됩니다. 이 평문 패킷에 대해 conntrack → flowtable → DPI 파이프라인이 정상 작동합니다. 송신 시에는 flowtable이 평문 패킷을 NIC에 전달하고, NIC이 ESP 캡슐화와 암호화를 인라인으로 수행합니다.

# IPSec + flowtable NGFW 조합 설정
# 1. xfrm SA에 crypto offload 설정
ip xfrm state add src 10.0.0.1 dst 10.0.0.2 \
  proto esp spi 0x1001 reqid 1 mode tunnel \
  aead 'rfc4106(gcm(aes))' 0x$(head -c 20 /dev/urandom | xxd -p) 128 \
  offload crypto dev eth0 dir out

ip xfrm state add src 10.0.0.2 dst 10.0.0.1 \
  proto esp spi 0x1002 reqid 1 mode tunnel \
  aead 'rfc4106(gcm(aes))' 0x$(head -c 20 /dev/urandom | xxd -p) 128 \
  offload crypto dev eth0 dir in

# 2. xfrm 정책
ip xfrm policy add src 10.1.0.0/24 dst 10.2.0.0/24 \
  dir out tmpl src 10.0.0.1 dst 10.0.0.2 \
  proto esp reqid 1 mode tunnel

# 3. flowtable에서 decrypted 패킷 오프로드
nft add flowtable inet ngfw ft_ipsec \
  { hook ingress priority 0\; devices = { eth0 }\; flags offload\; }

nft add rule inet ngfw forward \
  ct state established \
  ipsec in reqid 1 \
  flow add @ft_ipsec accept

# 확인: IPSec HW 오프로드 상태
ip xfrm state show | grep -A1 offload
ethtool -S eth0 | grep ipsec

NGFW에서 VXLAN 오버레이 + 보안 통합

데이터센터 NGFW에서 VXLAN 오버레이 네트워크와 보안 검사를 통합하는 아키텍처입니다. eSwitch가 VXLAN 터널의 encap/decap을 하드웨어에서 수행하고, 내부 패킷에 대해 conntrack + DPI를 적용합니다.

# VXLAN + NGFW 통합 구성 (eSwitch offload)

# 1. VXLAN 터널 엔드포인트 생성
ip link add vxlan100 type vxlan id 100 \
  local 10.0.0.1 dport 4789 nolearning external

# 2. nftables에서 decap된 내부 트래픽에 NGFW 정책 적용
table inet vxlan_ngfw {
    flowtable ft_vxlan {
        hook ingress priority 0
        devices = { vxlan100, eth1 }
        flags offload
    }

    chain forward {
        type filter hook forward priority 0; policy drop;
        ct state invalid drop

        # VXLAN 내부 트래픽: EST → offload
        iifname "vxlan100" ct state established,related \
            flow add @ft_vxlan accept

        # VXLAN 내부 트래픽: NEW → DPI
        iifname "vxlan100" ct state new \
            queue num 0-3 fanout

        # 내부 → VXLAN: EST → offload
        oifname "vxlan100" ct state established,related \
            flow add @ft_vxlan accept
    }
}

# 3. eSwitch에서 VXLAN + conntrack 통합 규칙
# 외부 헤더로 VXLAN 패킷 식별 → decap → conntrack → forward
tc filter add dev eth0_rep0 ingress chain 0 prio 1 \
  protocol ip flower \
  enc_dst_ip 10.0.0.1 enc_dst_port 4789 enc_key_id 100 \
  action tunnel_key unset pipe \
  action ct zone 2 pipe \
  action goto chain 1

# chain 1에서 EST/NEW 분기 (위 §8 패턴과 동일)
tc filter add dev eth0_rep0 ingress chain 1 prio 1 \
  protocol ip flower ct_state +trk+est \
  action ct zone 2 nat pipe \
  action mirred egress redirect dev eth1_rep0

tc filter add dev eth0_rep0 ingress chain 1 prio 2 \
  protocol ip flower ct_state +trk+new \
  action pass

GTP-U 오프로드와 5G NGFW

5G 모바일 네트워크에서 사용자 트래픽은 GTP-U(GPRS Tunnelling Protocol User Plane)로 캡슐화되어 전송됩니다. NGFW가 5G 환경에 배치되면 GTP-U 터널 내부의 실제 사용자 트래픽을 검사해야 하며, 이때 GTP-U 디캡슐레이션(Decapsulation)과 내부 패킷 검사를 SmartNIC 하드웨어에서 오프로드하면 처리량을 극대화할 수 있습니다. 이 섹션에서는 GTP-U 프로토콜 구조, 커널 GTP 모듈, TC flower 연동, HW 오프로드 구현을 다룹니다.

GTP-U 프로토콜 구조

GTP-U(GPRS Tunnelling Protocol - User Plane)는 3GPP 표준(TS 29.281)에 정의된 터널링 프로토콜로, 모바일 네트워크에서 사용자 데이터 패킷을 캡슐화하여 네트워크 노드 간에 전달합니다. GTP-U는 UDP 포트 2152 위에서 동작하며, 핵심 식별자는 TEID(Tunnel Endpoint Identifier)입니다.

GTP-U 헤더 형식

GTP-U 캡슐화 스택

GTP-U로 캡슐화된 패킷의 전체 프로토콜 스택은 다음과 같습니다:

┌─────────────────────────────────────────────────────────────────────┐
│ Outer Ethernet │ Outer IP │ UDP(2152) │ GTP-U │ Inner IP │ Payload │
├────────────────┼──────────┼───────────┼───────┼──────────┼─────────┤
│    14 bytes    │ 20 bytes │  8 bytes  │ 8~12B │ 20 bytes │  ...    │
└────────────────┴──────────┴───────────┴───────┴──────────┴─────────┘
                                         
총 오버헤드: 14 + 20 + 8 + 8(~12) = 50~54 bytes (Inner Ethernet 없음)
1500B MTU 기준 실효 페이로드: 1446~1450 bytes

모바일 네트워크에서 NGFW 배치 위치

5G 네트워크 아키텍처(3GPP TS 23.501)에서 NGFW는 주로 N3 인터페이스(gNB ↔ UPF)와 N6 인터페이스(UPF ↔ Data Network) 두 위치에 배치됩니다.

5G 아키텍처 개요

5G 데이터 플레인 경로:

  UE ──[무선]──→ gNB ──[N3: GTP-U]──→ UPF ──[N6: IP]──→ DN (Internet)
                  │                     │
                  │   ┌──[N9: GTP-U]──┐ │
                  │   │  (UPF 간 중계)  │ │
                  │   └───────────────┘ │
                  │                     │
              ┌───┴───────────────┐   ┌─┴──────────┐
              │  NGFW 위치 A      │   │ NGFW 위치 B │
              │  (N3 인라인)       │   │ (N6 이그레스)│
              │  GTP-U 내부 검사  │   │ 일반 IP 검사 │
              └───────────────────┘   └────────────┘

N3 인라인 배치 시 트래픽 패턴

N3 인터페이스에 NGFW를 배치하면 모든 사용자 트래픽이 GTP-U로 캡슐화된 상태로 통과합니다. NGFW는 다음과 같은 처리를 수행해야 합니다:

• GTP-U 디캡슐레이션 — 외부 Ethernet/IP/UDP/GTP-U 헤더를 제거하여 내부(Inner) IP 패킷을 추출합니다.
• TEID 기반 세션 매핑 — TEID를 사용자(가입자) 세션에 매핑합니다. 단일 UPF에 10만~100만 개의 동시 TEID가 존재할 수 있습니다.
• Inner 패킷 검사 — 추출된 내부 IP 패킷에 대해 ACL, conntrack, DPI, IPS를 수행합니다.
• GTP-U 재캡슐레이션 — 검사 완료 후 원래의 GTP-U 헤더를 재부착하여 전달합니다.

N6 이그레스 배치 시 장단점

N6 인터페이스에서는 UPF가 이미 GTP-U 디캡슐레이션을 완료했으므로, NGFW는 일반 IP 패킷을 처리합니다. 이 경우 GTP-U 처리 오버헤드가 없어 기존 NGFW 파이프라인을 그대로 사용할 수 있지만, TEID 기반 가입자 식별이 불가능하다는 단점이 있습니다. 가입자별 정책(Per-Subscriber Policy)을 적용하려면 UPF가 내부 IP에 DSCP 마킹이나 VLAN 태그로 가입자 정보를 전달해야 합니다.

커널 GTP 모듈과 TC flower 연동

Linux 커널은 gtp.ko 모듈을 통해 GTP-U 터널 인터페이스를 제공합니다. 이 모듈은 커널 4.7부터 포함되어 있으며, Open5GS, free5GC 등 오픈소스 5G 코어에서 UPF 구현에 사용됩니다.

gtp.ko 모듈 아키텍처

# GTP 커널 모듈 로드
modprobe gtp

# GTP 터널 인터페이스 생성 (libgtpnl 사용)
# gtp-link 명령은 genl(generic netlink) 기반
ip link add gtp0 type gtp role sgsn hashsize 131072

# 또는 gtp_newlink netlink API로 직접 생성
# (Open5GS UPF가 내부적으로 사용하는 방식)

# GTP 인터페이스 상태 확인
ip link show gtp0
ip addr add 10.45.0.1/16 dev gtp0
ip link set gtp0 up

# GTP 터널 세션(PDP context) 추가
# TEID 0x12345678, peer 192.168.1.100 (gNB IP)
gtp-tunnel add gtp0 v1 12345678 192.168.1.100 10.45.0.2

/* drivers/net/gtp.c - GTP-U 수신 처리 */
static int gtp1u_udp_encap_recv(struct sock *sk, struct sk_buff *skb)
{
    struct gtphdr *gtp1;
    struct pdp_ctx *pctx;

    /* GTP-U 헤더 파싱 */
    gtp1 = (struct gtphdr *)(skb->data + sizeof(struct udphdr));
    
    if ((gtp1->flags >> 5) != GTP_V1)
        return 1;  /* not GTPv1 */
    
    if (gtp1->type != GTP_TPDU)
        return 1;  /* not T-PDU (user data) */

    /* TEID로 PDP context (세션) 조회 */
    pctx = gtp1_pdp_find(gtp, ntohl(gtp1->tid));
    if (!pctx)
        return -1;  /* unknown TEID */

    /* outer 헤더 제거, inner IP 패킷 노출 */
    skb_pull(skb, hdrlen);
    
    /* inner 패킷을 GTP 인터페이스(gtp0)로 수신 처리 */
    skb->dev = gtp->dev;
    netif_rx(skb);
    return 0;
}

TC flower로 GTP-U 매칭

커널 5.7부터 TC flower는 enc_key_id 필드로 GTP-U의 TEID를 매칭할 수 있습니다. 이를 통해 특정 TEID(가입자 세션)에 대한 정책을 TC flower 규칙으로 설정할 수 있습니다.

# TC flower로 GTP-U TEID 매칭
# enc_key_id = TEID (tunnel key)

# 1. GTP-U 터널의 특정 TEID에 대한 트래픽 미러링
tc filter add dev eth0 ingress protocol ip \
    flower \
    enc_key_id 0x12345678 \
    enc_dst_port 2152 \
    action mirred egress mirror dev mon0

# 2. 특정 TEID의 inner IP 기반 ACL
tc filter add dev eth0 ingress protocol ip \
    flower \
    enc_key_id 0x12345678 \
    enc_dst_port 2152 \
    enc_src_ip 192.168.1.100 \
    ip_proto tcp \
    dst_port 443 \
    action pass

# 3. tunnel_key 액션으로 GTP-U decap
tc filter add dev eth0 ingress protocol ip \
    flower \
    enc_dst_port 2152 \
    action tunnel_key unset \
    action mirred egress redirect dev gtp_decap0

# 4. 결합: GTP decap + conntrack + NAT
tc filter add dev eth0 ingress protocol ip \
    flower \
    enc_dst_port 2152 \
    enc_key_id 0x12345678 \
    action tunnel_key unset \
    action ct zone 100 \
    action ct commit zone 100 nat src addr 203.0.113.1 \
    action mirred egress redirect dev eth1

GTP-U HW 오프로드 구현

NVIDIA ConnectX-7(BlueField-3)은 GTP-U 하드웨어 디캡슐레이션을 지원하는 대표적인 SmartNIC입니다. GTP-U decap을 TC flower와 결합하면 디캡슐레이션, conntrack, NAT, ACL을 단일 HW 파이프라인에서 처리할 수 있습니다.

NVIDIA ConnectX-7 GTP-U 오프로드

# ConnectX-7 eSwitch 모드 설정
devlink dev eswitch set pci/0000:03:00.0 mode switchdev

# GTP-U decap offload 활성화
# representor 인터페이스에서 GTP-U 터널 매칭

# 1단계: GTP-U decap + inner 패킷 추출
tc filter add dev eth0_rep ingress protocol ip \
    flower \
    enc_dst_port 2152 \
    enc_key_id 0x12345678 \
    action tunnel_key unset pipe \
    action goto chain 1

# 2단계: chain 1에서 inner 패킷에 대해 conntrack
tc filter add dev eth0_rep ingress chain 1 protocol ip \
    flower \
    ct_state -trk \
    action ct zone 100 pipe \
    action goto chain 2

# 3단계: chain 2에서 ESTABLISHED 세션 offload
tc filter add dev eth0_rep ingress chain 2 protocol ip \
    flower \
    ct_state +trk+est \
    action ct commit zone 100 nat pipe \
    action tunnel_key set \
    id 0x87654321 \
    dst_ip 10.100.1.1 \
    dst_port 2152 \
    action mirred egress redirect dev eth1_rep

# NEW 세션은 SW로 (Slow Path)
tc filter add dev eth0_rep ingress chain 2 protocol ip \
    flower \
    ct_state +trk+new \
    action trap

위 규칙이 eSwitch FDB에 설치되면, 확립된 GTP-U 세션의 패킷은 다음 HW 파이프라인을 거칩니다:

ConnectX-7 HW 파이프라인 (GTP-U offload):

  NIC RX → TEID 매칭 → GTP-U decap → inner IP 추출
  → CT lookup (zone 100) → EST 매칭 → NAT rewrite
  → GTP-U encap (new TEID) → TX → Wire

  전체 과정이 NIC 하드웨어에서 완료 (CPU 개입 없음)
  지연(Latency): ~5μs (SW 경로 대비 1/100)

Stateful GTP 검사 파이프라인

완전한 5G NGFW HW 오프로드 파이프라인은 다음 요소를 결합합니다:

5G NGFW 오프로드 성능 특성

5G NGFW 오프로드의 성능은 가입자 세션 밀도, GTP-U 오버헤드, 오프로드 비율에 따라 크게 달라집니다.

가입자 세션 밀도

5G UPF의 가입자 세션 규모는 다음과 같습니다:

GTP-U 오버헤드 분석

SW 전용 vs HW 오프로드 성능 비교

오프로드 효과 분석

HW 오프로드의 효과는 트래픽 프로파일(Profile)에 따라 달라집니다:

처리량 모델 (100Gbps 환경):

  총 트래픽: 100 Gbps
  
  시나리오 1: 오프로드 비율 0% (SW 전용)
    CPU 필요: 100Gbps ÷ 10Gbps/코어 = 10코어 (GTP decap + CT + NAT)
    DPI 추가 시: 100Gbps ÷ 3Gbps/코어 = 33코어
    → 총 33+ CPU 코어 필요 (불가능에 가까움)

  시나리오 2: 오프로드 비율 80%
    HW 처리: 80 Gbps (CPU 부하 없음)
    SW 처리: 20 Gbps → 20 ÷ 10 = 2코어 (EST)
    DPI (새 세션만): ~5 Gbps → 5 ÷ 3 = 2코어
    → 총 4 CPU 코어로 100Gbps 처리 가능

  시나리오 3: 오프로드 비율 90%
    HW 처리: 90 Gbps
    SW 처리: 10 Gbps → 1코어 (EST) + 1코어 (DPI)
    → 총 2 CPU 코어로 100Gbps 처리 가능

암/복호화 트래픽 HW 오프로드

NGFW에서 암호화 트래픽(Encrypted Traffic) 처리는 가장 CPU 집약적인 작업입니다. TLS 1.3 시대에 전체 웹 트래픽의 95% 이상이 암호화되어 있으며, NGFW는 이 트래픽을 복호화 → 검사(DPI/IPS) → 재암호화하거나, 암호화 상태로 메타데이터 기반 분류를 수행해야 합니다. 이 절에서는 NIC/SmartNIC/전용 ASIC에서 암·복호화를 하드웨어로 오프로드하는 모든 방식을 심층 분석합니다.

암호화 기술별 아키텍처 매핑

NGFW에서 사용되는 주요 암호화 오프로드 기술을 3대 아키텍처로 분류하면 다음과 같습니다. 동일 프로토콜이라도 오프로드 모드에 따라 아키텍처가 달라집니다.

아키텍처별 암호화 알고리즘 지원 매트릭스

아키텍처 유형에 따라 지원하는 암호화 알고리즘 범위가 크게 다릅니다. 인라인 방식은 NIC ASIC에 고정된 알고리즘만 지원하고, Lookaside 방식은 가속기 펌웨어로 더 넓은 알고리즘을 지원하며, CPU SW는 커널 crypto API의 모든 알고리즘을 지원합니다.

암호화 파이프라인 단계와 레이턴시

AES-256-GCM 암호화 한 패킷의 처리를 단계별로 분해하면, 각 아키텍처에서 병목이 되는 지점이 어디인지 명확해집니다. 아래 다이어그램은 1,400바이트 페이로드(일반 MTU) 기준의 처리 단계를 보여줍니다.

핵심 인사이트: CPU AES-NI는 패킷당 레이턴시가 가장 낮지만(~0.15μs, DMA 없음), 해당 코어를 100% 점유합니다. QAT Lookaside는 PCIe 왕복으로 레이턴시가 높지만(10-50μs), CPU를 해방하여 DPI에 활용할 수 있습니다. NIC Inline은 레이턴시와 처리량 모두 최적이지만 AES-GCM 외 알고리즘을 지원하지 않습니다. NGFW에서의 최적 전략은 트래픽 프로파일에 따라 아키텍처를 혼합하는 것입니다.

암호화 오프로드가 NGFW에서 중요한 이유

AES-256-GCM 암호화/복호화는 CPU 코어당 약 2~8 Gbps(AES-NI 활용 시)의 처리량을 제공합니다. 100Gbps 링크에서 전체 트래픽을 SSL Inspection 하려면 최소 12~50개 코어가 암호화 연산에만 필요합니다. HW 오프로드는 이 부담을 전용 실리콘으로 이전합니다.

kTLS (Kernel TLS) HW 오프로드

kTLS(Kernel TLS)는 TLS 레코드 계층(record layer)의 암·복호화를 커널에서 수행하는 메커니즘입니다. 유저스페이스 TLS 라이브러리(OpenSSL, GnuTLS)가 핸드셰이크를 완료하면, 대칭키와 암호화 파라미터를 setsockopt(SOL_TLS)로 커널에 전달합니다. 이후 데이터 전송은 커널이 직접 TLS 레코드를 구성하고, NIC이 인라인 암호화를 수행합니다.

kTLS의 하이브리드 아키텍처

kTLS는 단일 아키텍처가 아닌 하이브리드입니다. TLS 프로토콜의 두 단계(핸드셰이크와 레코드 전송)가 서로 다른 아키텍처에서 처리됩니다.

• 핸드셰이크 단계 (RSA/ECDHE 비대칭키): CPU에서 실행 — QAT Lookaside로 가속 가능
• 레코드 전송 단계 (AES-GCM 대칭키): NIC 인라인에서 실행 — 호스트 메모리 우회, 라인레이트

이 하이브리드 구조가 중요한 이유는 CPS 병목(핸드셰이크)과 처리량 병목(레코드 전송)을 각각 최적의 아키텍처로 해결하기 때문입니다.

kTLS 동작 모드

kTLS HW offload 설정과 커널 내부

/* 유저스페이스: OpenSSL로 TLS 핸드셰이크 후 kTLS 활성화 */
/* 1. 핸드셰이크 완료 후 대칭키 추출 */
SSL_set_fd(ssl, sockfd);
SSL_connect(ssl);   /* TLS 핸드셰이크 (RSA/ECDHE → CPU) */

/* 2. 커널에 TLS 파라미터 전달 (ULP 설정) */
struct tls12_crypto_info_aes_gcm_256 crypto_info;
crypto_info.info.version = TLS_1_3_VERSION;
crypto_info.info.cipher_type = TLS_CIPHER_AES_GCM_256;
/* iv, key, salt, rec_seq 설정 ... */

setsockopt(sockfd, SOL_TCP, TCP_ULP, "tls", sizeof("tls"));
setsockopt(sockfd, SOL_TLS, TLS_TX, &crypto_info, sizeof(crypto_info));
setsockopt(sockfd, SOL_TLS, TLS_RX, &crypto_info_rx, sizeof(crypto_info_rx));

/* 3. 이후 send()/sendfile()은 커널/NIC이 TLS 암호화 수행 */
sendfile(sockfd, filefd, NULL, file_size);  /* zero-copy TLS 전송 */

/* net/tls/tls_device.c — NIC HW offload 등록 경로 */
static int tls_set_device_offload(struct sock *sk,
                                  struct tls_context *ctx)
{
    struct net_device *netdev;
    struct tls_offload_context_tx *offload_ctx;

    /* NIC이 kTLS offload를 지원하는지 확인 */
    netdev = get_netdev_for_sock(sk);
    if (!netdev->tlsdev_ops ||
        !netdev->tlsdev_ops->tls_dev_add)
        return -EOPNOTSUPP;

    /* NIC 드라이버에 TLS 연결 등록 */
    /* 드라이버가 HW crypto context를 할당하고 키 설치 */
    rc = netdev->tlsdev_ops->tls_dev_add(netdev, sk,
        TLS_OFFLOAD_CTX_DIR_TX, &ctx->crypto_send.info);

    /* 성공 시 TLS_TX_DEVICE_OFFLOAD 플래그 설정 */
    /* → send() 호출 시 평문을 NIC에 전달, NIC이 TLS 레코드 구성 + 암호화 */
    ctx->tx_conf = TLS_HW;
    return 0;
}

# kTLS HW offload 지원 확인 및 활성화
ethtool -k eth0 | grep tls
# tls-hw-tx-offload: on
# tls-hw-rx-offload: on

# kTLS HW offload 활성화
ethtool -K eth0 tls-hw-tx-offload on
ethtool -K eth0 tls-hw-rx-offload on

# kTLS 통계 확인
cat /proc/net/tls_stat
# TlsCurrTxSw: 0
# TlsCurrRxSw: 0
# TlsCurrTxDevice: 1234    ← HW TX offload 활성 연결 수
# TlsCurrRxDevice: 1230    ← HW RX offload 활성 연결 수
# TlsTxDevice: 56789       ← 누적 HW TX offload 연결 수
# TlsRxDevice: 55432       ← 누적 HW RX offload 연결 수
# TlsDecryptError: 3       ← HW 복호화 오류 (무결성 실패)

# NIC별 kTLS 카운터
ethtool -S eth0 | grep -i tls
# tx_tls_encrypted_packets: 1234567
# tx_tls_encrypted_bytes: 987654321
# tx_tls_ooo: 0           ← out-of-order resync 횟수
# tx_tls_drop_no_sync_data: 0
# rx_tls_decrypted_packets: 1234000
# rx_tls_decrypted_bytes: 980000000
# rx_tls_resync_req_pkt: 5
# rx_tls_resync_req_start: 2
# rx_tls_resync_req_end: 2

kTLS와 NGFW의 통합

kTLS를 NGFW에 활용하는 핵심 패턴은 SSL Inspection 프록시의 재암호화 가속입니다. NGFW가 SSL MITM(Man-In-The-Middle) 프록시로 동작할 때, 클라이언트→NGFW 복호화 후 DPI를 수행하고, NGFW→서버 재암호화 시 kTLS HW offload로 CPU 부담을 제거합니다.

kTLS HW offload NIC 호환성

IPSec HW 오프로드 모드

IPSec 오프로드는 암호화 깊이에 따라 3가지 모드로 구분됩니다. NGFW에서 각 모드는 보안 검사 파이프라인과의 통합 방식이 다릅니다. 핵심적으로, 이 3가지 모드는 3대 아키텍처의 Lookaside에서 Inline으로의 연속적인 스펙트럼입니다.

IPSec 3가지 모드의 아키텍처 분류

Crypto Offload 모드

Crypto offload는 가장 기본적인 IPSec HW 가속이며, CPU중심 Lookaside 아키텍처에 해당합니다. NIC이 AES-GCM 암·복호화만 수행하고, ESP 헤더 구성/파싱, SA(Security Association) 관리, 라우팅은 모두 커널 xfrm 스택이 처리합니다.

/* Crypto offload 모드의 패킷 처리 흐름 */

/* [수신 경로] */
NIC_RX:
  → ESP 패킷 수신
  → /* NIC HW: AES-GCM 복호화 + ICV 검증 */
  → /* skb에 복호화된 페이로드 + crypto 결과 태그 */
  → xfrm_input()
    → xfrm_state_lookup()       /* SPI → SA 매핑 */
    → /* HW가 이미 복호화 완료: crypto 연산 skip */
    → xfrm_parse_spi()          /* ESP 헤더 파싱 (CPU) */
    → xfrm_rcv_esp()
      → skb_pull(sizeof(esphdr)) /* ESP 헤더 제거 (CPU) */
      → xfrm_input_resume()
        → /* 내부 IP 패킷 → netfilter 훅 진입 */
        → /* conntrack → DPI 가능 */

/* [송신 경로] */
xfrm_output():
  → xfrm_output_one()
    → esp_output_head()          /* ESP 헤더 + IV + padding 구성 (CPU) */
    → /* NIC HW: AES-GCM 암호화 + ICV 생성 */
    → /* skb에 ESP 헤더 + 암호화된 페이로드 */
  → NIC_TX

# Crypto offload 설정
ip xfrm state add src 10.0.0.1 dst 10.0.0.2 \
  proto esp spi 0x1001 reqid 1 mode tunnel \
  aead 'rfc4106(gcm(aes))' 0x$(head -c 20 /dev/urandom | xxd -p) 128 \
  offload crypto dev eth0 dir out

# offload 상태 확인
ip xfrm state show
# ... offload type crypto dev eth0 dir out

# NIC crypto 카운터
ethtool -S eth0 | grep -i ipsec
# tx_ipsec_encrypt: 1234567
# rx_ipsec_decrypt: 1234000
# rx_ipsec_auth_fail: 0

Packet Offload 모드

Packet offload는 crypto offload에 더해 ESP 헤더 구성/파싱, 패딩, 시퀀스 번호 관리까지 NIC에서 수행합니다. 커널은 평문 IP 패킷을 NIC에 전달하기만 하면 됩니다.

/* Packet offload 모드: 커널에서 평문 IP 패킷만 전달 */

/* [수신] NIC이 ESP 헤더 파싱 + 복호화 + 헤더 제거 */
NIC_RX:
  → ESP 패킷 수신
  → /* NIC HW: SPI lookup → SA 확인 */
  → /* NIC HW: ESP 헤더 제거 + AES-GCM 복호화 + ICV 검증 */
  → /* NIC HW: 시퀀스 번호 anti-replay 검사 */
  → /* 결과: 순수 내부 IP 패킷이 호스트에 전달 */
  → /* skb→sp에 xfrm_state 참조 설정 (정책 검증용) */
  → netif_receive_skb()  /* → 일반 IP 패킷처럼 처리 */
    → nf_hook(PREROUTING) → conntrack → nftables → DPI

/* [송신] 커널이 평문 IP 패킷 전달 → NIC이 ESP 캡슐화 + 암호화 */
ip_output():
  → /* xfrm lookup → 해당 SA의 offload mode 확인 */
  → /* 평문 IP 패킷을 NIC TX 큐에 전달 */
  → /* NIC HW: ESP 헤더 추가 + padding + 시퀀스 번호 */
  → /* NIC HW: AES-GCM 암호화 + ICV 생성 */
  → /* 완성된 ESP 패킷 wire에 전송 */

# Packet offload 설정
ip xfrm state add src 10.0.0.1 dst 10.0.0.2 \
  proto esp spi 0x1001 reqid 1 mode tunnel \
  aead 'rfc4106(gcm(aes))' 0x$(head -c 20 /dev/urandom | xxd -p) 128 \
  offload packet dev eth0 dir out

# Crypto vs Packet offload 성능 차이 확인
# iperf3로 IPSec 터널 처리량 측정
iperf3 -c 10.2.0.1 -t 30 -P 4
# Crypto offload: ~25 Gbps (ESP 헤더 처리가 CPU 병목)
# Packet offload: ~50 Gbps (전체 ESP 처리 HW)

Full Offload 모드

Full offload는 packet offload에 추가로 라우팅/포워딩까지 NIC eSwitch에서 수행합니다. IPSec 터널의 내부 패킷이 eSwitch FDB 규칙에 매칭되면, 복호화 → 포워딩 → 재암호화가 모두 NIC 내부에서 완료되어 CPU를 전혀 사용하지 않습니다.

# Full offload: eSwitch + IPSec 결합
# 1. SA를 full offload 모드로 설정
ip xfrm state add src 10.0.0.1 dst 10.0.0.2 \
  proto esp spi 0x1001 reqid 1 mode tunnel \
  aead 'rfc4106(gcm(aes))' 0x$(head -c 20 /dev/urandom | xxd -p) 128 \
  offload packet dev eth0 dir out

ip xfrm state add src 10.0.0.2 dst 10.0.0.1 \
  proto esp spi 0x1002 reqid 1 mode tunnel \
  aead 'rfc4106(gcm(aes))' 0x$(head -c 20 /dev/urandom | xxd -p) 128 \
  offload packet dev eth0 dir in

# 2. eSwitch에서 decrypted inner 패킷을 직접 포워딩
# TC flower로 IPSec decrypted + EST 세션 → HW forward
tc filter add dev eth0_rep0 ingress chain 0 prio 1 \
  protocol ip flower \
  ct_state +trk+est \
  enc_type ipsec \
  action ct zone 1 nat pipe \
  action mirred egress redirect dev eth1_rep0

# 결과: 암호화된 패킷 수신 → NIC 내부에서 decrypt → forward → encrypt → 송신
# CPU 사용률: 거의 0% (ESTABLISHED 세션)

IPSec HW offload NIC 호환성 매트릭스

MACsec HW 오프로드

MACsec(IEEE 802.1AE)는 L2(이더넷 프레임) 수준의 암호화를 제공합니다. IPSec이 L3 이상을 보호하는 반면, MACsec는 이더넷 프레임 전체를 암호화하여 같은 L2 세그먼트 내의 도청/변조를 방지합니다.

MACsec과 NGFW의 관계

• 데이터센터 내부 보안: 서버 간 East-West 트래픽을 L2에서 암호화. NGFW는 MACsec 복호화 후 L3/L4 검사 수행
• Zero Trust 네트워크: 모든 L2 세그먼트에서 암호화를 기본 적용하고, NGFW가 복호화된 트래픽만 검사
• HW offload 필수: MACsec 암·복호화가 SW면 라인레이트 불가. NIC HW offload로 성능 유지

# MACsec HW offload 설정
# 1. MACsec 인터페이스 생성 (offload 모드)
ip link add link eth0 macsec0 type macsec \
  sci ff:ff:ff:ff:ff:ff:00:01 \
  encrypt on protect on \
  offload mac

# 2. 수신 SA 추가
ip macsec add macsec0 rx sci ff:ff:ff:ff:ff:ff:00:02 sa 0 \
  pn 1 on key 00 $(head -c 16 /dev/urandom | xxd -p)

# 3. 송신 SA 추가
ip macsec add macsec0 tx sa 0 \
  pn 1 on key 01 $(head -c 16 /dev/urandom | xxd -p)

# 4. 인터페이스 활성화
ip link set macsec0 up
ip addr add 10.0.0.1/24 dev macsec0

# offload 상태 확인
ip macsec show
# TXSC: ... (offload: mac)
# RXSC: ... (offload: mac)

# NIC MACsec 카운터
ethtool -S eth0 | grep -i macsec
# tx_macsec_pkts: 1234567
# rx_macsec_pkts: 1234000
# rx_macsec_decrypt_fail: 0

MACsec offload NIC 지원 현황

전용 크립토 가속기 (Intel QAT, Marvell NITROX)

NIC inline crypto와 별도로, 전용 크립토 가속 카드는 대량의 비대칭키 연산(RSA/ECDHE 핸드셰이크)과 대칭키 암호화를 모두 처리할 수 있습니다. NGFW에서 SSL Inspection의 TLS 핸드셰이크 병목(CPS 한계)을 해소하는 핵심 구성 요소입니다.

주요 크립토 가속기 비교

Intel QAT와 Linux crypto API 연동

/* Linux crypto API를 통한 QAT 가속 사용 */
/* 커널이 자동으로 HW 가속기를 선택하는 구조 */

/* 1. crypto API에서 알고리즘 요청 */
struct crypto_aead *aead;
aead = crypto_alloc_aead("gcm(aes)", 0, 0);
/* → 커널이 우선순위에 따라 선택: */
/*   1. QAT HW 가속 드라이버 (최고 우선순위) */
/*   2. AES-NI (CPU 가속) */
/*   3. 일반 SW 구현 (최저) */

/* 2. 비동기(Async) 암호화 요청 */
struct aead_request *req;
req = aead_request_alloc(aead, GFP_KERNEL);
aead_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
                          crypto_complete_cb, &result);
aead_request_set_crypt(req, src_sg, dst_sg, plaintext_len, iv);
aead_request_set_ad(req, aad_len);

/* 3. 비동기 전송 → QAT 엔진이 처리 */
ret = crypto_aead_encrypt(req);
if (ret == -EINPROGRESS || ret == -EBUSY) {
    /* QAT가 비동기로 처리 중 → 콜백에서 완료 통지 */
    wait_for_completion(&result.completion);
}

# Intel QAT 상태 확인
# 모듈 로드
modprobe qat_4xxx    # 또는 qat_c62x (PCIe 카드)
modprobe intel_qat

# QAT 디바이스 확인
lspci | grep -i "Co-processor\|DH895\|C62x\|4xxx"
# 0000:6b:00.0 Co-processor: Intel Corporation 4xxx Series (rev 02)

# QAT 서비스 상태
adf_ctl status
# qat_dev0 - type: 4xxx, ... state: up

# crypto API에 등록된 가속기 확인
cat /proc/crypto | grep -B2 "driver.*qat"
# name         : gcm(aes)
# driver       : gcm-aes-qat
# priority     : 4001

# IPSec에서 QAT 자동 활용 확인
# xfrm SA가 gcm(aes)를 사용하면 QAT가 자동으로 선택됨
ip xfrm state add src 10.0.0.1 dst 10.0.0.2 \
  proto esp spi 0x1001 reqid 1 mode tunnel \
  aead 'rfc4106(gcm(aes))' 0x$(head -c 20 /dev/urandom | xxd -p) 128

# QAT 성능 카운터
cat /sys/kernel/debug/qat_4xxx_0000:6b:00.0/fw_counters
# 또는 OpenSSL QAT 엔진 벤치마크
openssl speed -engine qatengine -evp aes-256-gcm -bytes 8192 -seconds 10

SSL/TLS 검사(Inspection) 오프로드 파이프라인

NGFW에서 SSL/TLS 암호화 트래픽을 검사하는 방식은 크게 4가지로 분류됩니다. 각 방식은 보안 수준, 성능, 구현 복잡도에서 다른 트레이드오프를 가집니다.

방식 1: SSL MITM 프록시 (Forward Proxy)

가장 전통적인 SSL Inspection 방법입니다. NGFW가 클라이언트와 서버 사이에서 두 개의 별도 TLS 세션을 수립하고, 중간에서 평문을 검사합니다.

방식 2: 인증서 기반 복호화 (Inbound Inspection)

NGFW가 서버의 개인키(Private Key)를 보유하고, 인바운드 TLS 트래픽을 수동적으로 복호화합니다. MITM이 아닌 패시브 복호화이므로 클라이언트에 인증서를 설치할 필요가 없습니다.

• 적용 대상: 기업 내부 웹 서버, API 게이트웨이 앞단의 NGFW
• 제한: PFS(Perfect Forward Secrecy) cipher suite(ECDHE) 사용 시 세션키 추출 불가 → RSA 키 교환만 가능 (TLS 1.3에서는 불가)
• 대안: TLS 1.3에서는 서버가 세션 키를 NGFW에 전달하는 키 에스크로(Key Escrow) 방식 또는 eBPF 기반 세션키 추출

방식 3: eBPF 기반 TLS 가시성 (에이전트 방식)

호스트에 eBPF 프로그램을 배포하여 TLS 라이브러리(OpenSSL/BoringSSL)의 SSL_read()/SSL_write()를 후킹하고, 평문 데이터를 캡처합니다. NGFW의 네트워크 경로에서 복호화할 필요가 없으므로 성능 영향이 최소화됩니다.

/* eBPF: OpenSSL SSL_write() uprobe로 평문 캡처 */
SEC("uprobe/SSL_write")
int probe_ssl_write(struct pt_regs *ctx)
{
    void *ssl = (void *)PT_REGS_PARM1(ctx);
    void *buf = (void *)PT_REGS_PARM2(ctx);
    int num = (int)PT_REGS_PARM3(ctx);

    /* 평문 데이터를 ring buffer로 전달 */
    struct ssl_data_t data = {};
    data.pid = bpf_get_current_pid_tgid() >> 32;
    data.len = num < 256 ? num : 256;
    bpf_probe_read_user(data.buf, data.len, buf);

    bpf_ringbuf_output(&events, &data, sizeof(data), 0);
    return 0;
}

방식 4: 메타데이터 기반 분류 (복호화 없는 검사)

TLS 트래픽을 복호화하지 않고, 외부에서 관찰 가능한 메타데이터만으로 위협을 탐지합니다:

• JA4/JA4+ 핑거프린팅: TLS Client Hello의 구조적 특성으로 클라이언트/악성코드 식별
• 인증서 분석: 서버 인증서의 CN/SAN, 발급자, 유효기간 검사 (TLS 1.2에서만)
• DNS 상관분석: DNS 쿼리와 TLS 연결을 연계하여 목적지 도메인 추론
• 트래픽 패턴 분석: 패킷 크기/타이밍 분포로 애플리케이션 유형 추론 (머신러닝 기반)
• ESNI/ECH 탐지: ECH 사용 여부를 탐지하여 정책 적용 (차단 또는 추가 검사)

NGFW 암호화 오프로드 통합 구성 예제

아래 3가지 패턴은 3대 아키텍처의 서로 다른 조합으로, NGFW의 요구사항(VPN, SSL Inspection, 클라우드)에 따라 최적의 하이브리드 구성을 보여줍니다.

패턴 1: IPSec Full Offload + flowtable + DPI 조합 [인라인 아키텍처]

VPN 게이트웨이 역할의 NGFW에서, IPSec 복호화 → DPI → 오프로드 → IPSec 재암호화 전체 파이프라인을 구성합니다. 이 패턴은 인라인 아키텍처의 대표적 활용으로, SmartNIC eSwitch가 IPSec + 포워딩을 모두 처리합니다:

#!/bin/bash
# NGFW VPN Gateway: IPSec Full Offload + DPI 통합 구성
# NIC: NVIDIA ConnectX-7 (IPSec packet offload + eSwitch)

# === 1. eSwitch switchdev 모드 활성화 ===
devlink dev eswitch set pci/0000:03:00.0 mode switchdev

# === 2. IPSec SA 설정 (packet offload) ===
# 원격 사이트와의 IPSec 터널 (AES-256-GCM)
KEY_OUT=$(head -c 36 /dev/urandom | xxd -p)
KEY_IN=$(head -c 36 /dev/urandom | xxd -p)

ip xfrm state add src 10.0.0.1 dst 10.0.0.2 \
  proto esp spi 0x1001 reqid 1 mode tunnel \
  aead 'rfc4106(gcm(aes))' 0x${KEY_OUT} 128 \
  offload packet dev eth0 dir out

ip xfrm state add src 10.0.0.2 dst 10.0.0.1 \
  proto esp spi 0x1002 reqid 1 mode tunnel \
  aead 'rfc4106(gcm(aes))' 0x${KEY_IN} 128 \
  offload packet dev eth0 dir in

# xfrm 정책
ip xfrm policy add src 10.1.0.0/24 dst 10.2.0.0/24 \
  dir out tmpl src 10.0.0.1 dst 10.0.0.2 \
  proto esp reqid 1 mode tunnel
ip xfrm policy add src 10.2.0.0/24 dst 10.1.0.0/24 \
  dir in tmpl src 10.0.0.2 dst 10.0.0.1 \
  proto esp reqid 1 mode tunnel

# === 3. nftables NGFW 규칙 (복호화된 내부 패킷에 적용) ===
nft -f - << 'EOF'
table inet vpn_ngfw {
    flowtable ft_vpn {
        hook ingress priority 0
        devices = { eth0, eth1 }
        flags offload
    }

    chain forward {
        type filter hook forward priority 0; policy drop;

        # EST 세션 → flowtable HW offload
        # (NIC이 decrypt → forward → re-encrypt 전구간 처리)
        ct state established,related flow add @ft_vpn counter accept

        # INVALID → drop
        ct state invalid counter drop

        # NEW → Suricata DPI (NFQUEUE)
        ct state new counter queue num 0-3 fanout,bypass
    }
}
EOF

# === 4. Suricata IPS 시작 (NFQUEUE 모드) ===
# suricata.yaml에서 nfqueue 모드 설정 필요
systemctl start suricata

# === 5. 확인 ===
echo "IPSec offload 상태:"
ip xfrm state show | grep -A1 offload
echo ""
echo "flowtable HW offload 확인:"
nft list flowtable inet vpn_ngfw ft_vpn
echo ""
echo "NIC 카운터:"
ethtool -S eth0 | grep -E "ipsec|flow_table"

패턴 2: SSL MITM 프록시 + QAT + kTLS 구성 [CPU Lookaside + 인라인 하이브리드]

HTTPS 트래픽을 복호화하여 DPI를 수행하는 SSL Inspection 구성입니다. 이 패턴은 CPU중심 Lookaside(QAT 핸드셰이크 가속)와 인라인(kTLS NIC 레코드 오프로드)의 하이브리드입니다. TLS 핸드셰이크는 QAT가, 레코드 암호화는 kTLS NIC offload가 처리합니다:

# SSL MITM NGFW 구성 (nginx reverse proxy + Suricata)

# === 1. QAT 활성화 ===
modprobe qat_4xxx
modprobe intel_qat

# === 2. kTLS NIC offload 활성화 ===
ethtool -K eth0 tls-hw-tx-offload on
ethtool -K eth0 tls-hw-rx-offload on

# === 3. nginx SSL 프록시 설정 (kTLS + QAT) ===
# /etc/nginx/nginx.conf
# ssl_engine qatengine;        # QAT 가속 핸드셰이크
# sendfile on;                 # kTLS + sendfile zero-copy
# ssl_conf_command Options KTLS;  # kTLS 활성화

# === 4. nftables: SSL 프록시로 리다이렉트 ===
nft -f - << 'EOF'
table inet ssl_inspect {
    chain prerouting {
        type nat hook prerouting priority -100; policy accept;

        # HTTPS 트래픽 → SSL 프록시 (nginx)로 REDIRECT
        tcp dport 443 redirect to :8443
    }

    chain forward {
        type filter hook forward priority 0; policy drop;

        # SSL 프록시가 복호화한 평문 → Suricata DPI
        iifname "lo" oifname "eth1" ct state new \
            queue num 0-3 fanout,bypass

        ct state established,related accept
    }
}
EOF

# === 5. QAT 성능 확인 ===
cat /proc/crypto | grep -A3 "driver.*qat"
adf_ctl status

패턴 3: eBPF TLS 가시성 + flowtable 오프로드 [CPU중심 + 인라인 하이브리드]

# eBPF 기반 TLS 가시성 (복호화 없이 평문 캡처)
# bpftrace로 OpenSSL SSL_write/SSL_read 후킹

# SSL_write 평문 캡처 (간단한 예시)
bpftrace -e '
  uprobe:/usr/lib/x86_64-linux-gnu/libssl.so.3:SSL_write {
    printf("PID %d SSL_write %d bytes\n", pid, arg2);
    /* 실제 환경에서는 ring buffer로 DPI 엔진에 전달 */
  }
  uprobe:/usr/lib/x86_64-linux-gnu/libssl.so.3:SSL_read_ex /retval > 0/ {
    printf("PID %d SSL_read %d bytes\n", pid, arg2);
  }
'

# 네트워크 경로에서는 암호화 유지 → 최고 성능
# flowtable HW offload 그대로 적용 가능
nft add flowtable inet filter ft \
  { hook ingress priority 0\; devices = { eth0, eth1 }\; flags offload\; }
nft add rule inet filter forward \
  ct state established flow add @ft accept

Regex/DPI 하드웨어 가속 엔진

NGFW의 핵심 기능인 심층 패킷 검사(DPI, Deep Packet Inspection)는 네트워크 트래픽의 페이로드(Payload)를 정규식(Regular Expression) 패턴으로 분석하여 악성 코드, 침입 시도, 애플리케이션 프로토콜을 식별합니다. 이 과정은 CPU 집약적이며, 10Gbps 이상의 환경에서 소프트웨어만으로는 라인 레이트 처리가 불가능합니다. 이 절에서는 정규식 매칭의 비용 구조와 하드웨어 가속 엔진 3종(NVIDIA RXP, Marvell REE, Intel Hyperscan+QAT)의 아키텍처 및 통합 방법을 다룹니다.

NGFW에서 정규식 매칭의 비용

IDS/IPS 엔진(Suricata, Snort)의 CPU 프로파일링(Profiling) 데이터를 보면, 멀티 패턴 매칭(Multi-Pattern Matching, MPM)이 전체 CPU 사이클의 40~60%를 소비합니다. 이는 수천 개의 시그니처(Signature)를 동시에 매칭해야 하기 때문입니다.

다음 명령으로 Suricata 프로세스의 CPU 프로파일을 수집할 수 있습니다.

# perf를 이용한 Suricata CPU 프로파일링 (30초 샘플링)
sudo perf record -g -p $(pidof suricata) -- sleep 30
sudo perf report --sort=dso,symbol --stdio | head -60

# 특정 함수별 CPU 비중 확인
sudo perf report --stdio --sort=symbol | grep -E "(SCACSearch|MpmSearch|DetectMatch)"

# bpftrace로 MPM 함수 레이턴시 분포 확인
sudo bpftrace -e '
uprobe:/usr/bin/suricata:SCACSearch {
    @start[tid] = nsecs;
}
uretprobe:/usr/bin/suricata:SCACSearch /@start[tid]/ {
    @latency_ns = hist(nsecs - @start[tid]);
    delete(@start[tid]);
}
interval:s:10 { exit(); }
'

# flamegraph 생성 (CPU 핫스팟 시각화)
sudo perf script | stackcollapse-perf.pl | flamegraph.pl > suricata-flame.svg

10Gbps 이상 환경에서 하드웨어 가속이 중요한 이유를 정리하면 다음과 같습니다.

• 결정론적 레이턴시: DFA 기반 하드웨어 엔진은 O(n) 처리 시간을 보장하므로, NFA 폴백으로 인한 지연 스파이크(Latency Spike)가 발생하지 않습니다.
• CPU 오프로드: 정규식 매칭을 전용 하드웨어에 위임하면 CPU 코어를 세션 관리, 정책 판단, 로깅 등 다른 작업에 할당할 수 있습니다.
• 확장성: 트래픽 증가 시 CPU 코어를 추가하는 것보다 하드웨어 엔진의 병렬 처리 유닛을 활용하는 것이 전력 효율과 비용 면에서 유리합니다.
• 일관된 처리량: 소프트웨어 MPM은 패턴 집합 크기에 따라 성능이 변동하지만, 하드웨어 엔진은 수만 개 패턴에서도 안정적인 처리량을 유지합니다.

NVIDIA BlueField-3 RXP 엔진

NVIDIA BlueField-3 DPU에 내장된 RXP(RegEx Processing Unit)는 하드웨어 DFA 기반 정규식 가속 엔진입니다. 최대 400Gbps의 정규식 매칭 처리량을 제공하며, DOCA(Data Center Infrastructure on a Chip Architecture) SDK를 통해 프로그래밍합니다.

RXP 엔진의 워크플로는 다음과 같습니다.

1. 규칙 컴파일: rxpc 컴파일러가 PCRE 형식의 정규식 패턴 파일(.rules)을 RXP 하드웨어가 이해하는 바이너리 규칙 파일(.rxp)로 변환합니다.
2. 엔진 초기화: DOCA RegEx 컨텍스트를 생성하고, 컴파일된 규칙을 RXP 엔진에 로드합니다.
3. 배치 제출: 검사할 패킷 버퍼들을 배치(Batch)로 묶어 RXP 엔진에 비동기 제출합니다.
4. 결과 수집: 폴링(Polling) 또는 이벤트 기반으로 매칭 결과를 수집하고, 매칭된 규칙 ID와 오프셋 정보를 확인합니다.

# rxpc를 이용한 규칙 컴파일
# 입력: PCRE 패턴 파일, 출력: RXP 바이너리 규칙
rxpc -f suricata_patterns.rules -o compiled_rules.rxp \
     --max-rules 10000 \
     --optimize-level 3

# 컴파일 결과 통계 확인
rxpc -f suricata_patterns.rules --stats-only
# 출력 예: Total rules: 8432, DFA states: 124567, Memory: 48MB

다음은 DOCA RegEx API를 사용한 정규식 하드웨어 가속 코드 예제입니다.

#include <doca_regex.h>
#include <doca_buf.h>
#include <doca_ctx.h>
#include <doca_dev.h>
#include <doca_error.h>
#include <doca_log.h>

DOCA_LOG_REGISTER(REGEX_DPI);

#define MAX_BATCH_SIZE  256
#define MAX_MATCHES     16

struct regex_dpi_ctx {
    struct doca_dev       *dev;
    struct doca_regex     *regex;
    struct doca_ctx       *ctx;
    struct doca_pe        *pe;       /* Progress engine */
    struct doca_buf_arr   *buf_arr;
    struct doca_mmap      *mmap;
    uint32_t               total_matches;
    uint32_t               total_scanned;
};

/* 매칭 완료 콜백 — 비동기 결과 처리 */
static void regex_task_completion_cb(struct doca_regex_task_search *task,
                                     union doca_data task_user_data,
                                     union doca_data ctx_user_data)
{
    struct regex_dpi_ctx *dpi = (struct regex_dpi_ctx *)ctx_user_data.ptr;
    struct doca_regex_search_result *result;
    uint32_t num_matches = 0;
    doca_error_t err;

    err = doca_regex_task_search_get_result(task, &result);
    if (err != DOCA_SUCCESS) {
        DOCA_LOG_WARN("regex result retrieval failed: %s",
                      doca_error_get_descr(err));
        goto cleanup;
    }

    num_matches = doca_regex_search_result_get_num_matches(result);
    if (num_matches > 0) {
        dpi->total_matches += num_matches;

        /* 매칭된 각 규칙 ID와 오프셋 순회 */
        for (uint32_t i = 0; i < num_matches && i < MAX_MATCHES; i++) {
            struct doca_regex_match *match;
            doca_regex_search_result_get_match(result, i, &match);

            uint32_t rule_id = doca_regex_match_get_rule_id(match);
            uint32_t offset  = doca_regex_match_get_offset(match);
            uint32_t length  = doca_regex_match_get_length(match);

            DOCA_LOG_DBG("Match: rule=%u offset=%u len=%u",
                         rule_id, offset, length);
        }
    }
    dpi->total_scanned++;

cleanup:
    doca_task_free(doca_regex_task_search_as_task(task));
}

/* RXP 엔진 초기화: 디바이스 탐색, 규칙 로드, 컨텍스트 생성 */
static doca_error_t init_regex_engine(struct regex_dpi_ctx *dpi,
                                      const char *rules_path)
{
    doca_error_t err;

    /* BlueField DPU의 RegEx 디바이스 열기 */
    err = doca_dev_open_by_capability(DOCA_DEV_CAP_REGEX, &dpi->dev);
    if (err != DOCA_SUCCESS) {
        DOCA_LOG_ERR("RegEx device not found: %s",
                     doca_error_get_descr(err));
        return err;
    }

    /* DOCA RegEx 인스턴스 생성 */
    err = doca_regex_create(dpi->dev, &dpi->regex);
    if (err != DOCA_SUCCESS)
        return err;

    /* 컴파일된 규칙 파일 로드 */
    err = doca_regex_set_hardware_compiled_rules(dpi->regex, rules_path);
    if (err != DOCA_SUCCESS) {
        DOCA_LOG_ERR("Failed to load rules from %s", rules_path);
        return err;
    }

    /* Progress Engine 생성 (비동기 태스크 관리) */
    err = doca_pe_create(&dpi->pe);
    if (err != DOCA_SUCCESS)
        return err;

    /* 컨텍스트 연결 및 시작 */
    dpi->ctx = doca_regex_as_ctx(dpi->regex);
    err = doca_pe_connect_ctx(dpi->pe, dpi->ctx);
    if (err != DOCA_SUCCESS)
        return err;

    /* 완료 콜백 설정 */
    union doca_data user_data = { .ptr = dpi };
    err = doca_regex_task_search_set_conf(
              dpi->regex,
              regex_task_completion_cb,  /* 성공 콜백 */
              regex_task_completion_cb,  /* 에러 콜백 */
              MAX_BATCH_SIZE);
    if (err != DOCA_SUCCESS)
        return err;

    err = doca_ctx_set_user_data(dpi->ctx, user_data);
    if (err != DOCA_SUCCESS)
        return err;

    return doca_ctx_start(dpi->ctx);
}

/* 패킷 버퍼 배치를 RXP 엔진에 제출 */
static doca_error_t submit_packet_batch(struct regex_dpi_ctx *dpi,
                                        void **pkt_bufs,
                                        uint32_t *pkt_lens,
                                        int count)
{
    doca_error_t err;

    for (int i = 0; i < count; i++) {
        struct doca_regex_task_search *task;
        struct doca_buf *buf;

        /* 패킷 데이터를 DOCA 버퍼에 매핑 */
        err = doca_buf_arr_get_buf(dpi->buf_arr, i, &buf);
        if (err != DOCA_SUCCESS)
            continue;

        doca_buf_set_data(buf, pkt_bufs[i], pkt_lens[i]);

        /* 검색 태스크 생성 및 제출 */
        union doca_data task_data = { .u64 = i };
        err = doca_regex_task_search_alloc_init(
                  dpi->regex, buf, task_data, &task);
        if (err != DOCA_SUCCESS)
            continue;

        err = doca_task_submit(
                  doca_regex_task_search_as_task(task));
        if (err != DOCA_SUCCESS) {
            doca_task_free(doca_regex_task_search_as_task(task));
            continue;
        }
    }

    /* Progress Engine 폴링 — 완료된 태스크의 콜백 호출 */
    while (dpi->total_scanned < (uint32_t)count) {
        (void)doca_pe_progress(dpi->pe);
    }

    return DOCA_SUCCESS;
}

Marvell REE (RegEx Engine)

Marvell OCTEON CN10K SoC에 내장된 REE(RegEx Engine)는 하드웨어 DFA/NFA 하이브리드 정규식 코프로세서(Coprocessor)입니다. DPDK의 rte_regexdev API를 통해 접근하며, 이벤트 기반 비동기 처리 모델을 지원합니다.

DPDK rte_regexdev API의 핵심 구성 요소는 다음과 같습니다.

• rte_regexdev_configure(): REE 디바이스를 초기화하고 큐 수, 규칙 DB 크기 등을 설정합니다.
• rte_regexdev_rule_db_update(): 컴파일된 규칙을 하드웨어에 로드합니다.
• rte_regexdev_enqueue_burst(): 검사 대상 버퍼를 배치로 제출합니다.
• rte_regexdev_dequeue_burst(): 완료된 매칭 결과를 배치로 수집합니다.
• eventdev 연동: rte_event_regex_adapter를 통해 이벤트 기반 비동기 파이프라인에 통합합니다.

#include <rte_regexdev.h>
#include <rte_mbuf.h>
#include <rte_log.h>

#define REGEX_DEV_ID    0
#define REGEX_QP_ID     0
#define BATCH_SIZE      64
#define MAX_MATCHES     8

/* REE 디바이스 초기화 및 규칙 로드 */
static int init_ree_device(const char *rules_file)
{
    struct rte_regexdev_config cfg = {
        .nb_queue_pairs   = 4,
        .nb_max_matches   = MAX_MATCHES,
        .nb_rules         = 10000,
        .rule_db_len      = 0,      /* 자동 감지 */
        .dev_cfg_flags    = 0,
    };
    struct rte_regexdev_info dev_info;
    int ret;

    /* 디바이스 정보 조회 */
    ret = rte_regexdev_info_get(REGEX_DEV_ID, &dev_info);
    if (ret < 0) {
        RTE_LOG(ERR, USER1, "REE device info failed: %d\n", ret);
        return ret;
    }
    RTE_LOG(INFO, USER1, "REE device: %s, max_rules=%u\n",
            dev_info.driver_name, dev_info.max_rules);

    /* 디바이스 설정 */
    ret = rte_regexdev_configure(REGEX_DEV_ID, &cfg);
    if (ret < 0)
        return ret;

    /* 규칙 DB 업데이트 — 컴파일된 바이너리 규칙 로드 */
    struct rte_regexdev_rule *rules;
    uint32_t nb_rules;

    /* 규칙 파일 파싱 (실제 구현에서는 파일 I/O) */
    ret = load_compiled_rules(rules_file, &rules, &nb_rules);
    if (ret < 0)
        return ret;

    ret = rte_regexdev_rule_db_update(REGEX_DEV_ID,
                                       rules, nb_rules);
    if (ret < 0)
        return ret;

    ret = rte_regexdev_rule_db_compile_activate(REGEX_DEV_ID);
    if (ret < 0)
        return ret;

    /* 큐 페어 설정 */
    struct rte_regexdev_qp_conf qp_conf = {
        .nb_desc = 1024,
        .qp_conf_flags = RTE_REGEX_QUEUE_PAIR_CFG_OOS_F,
    };
    ret = rte_regexdev_queue_pair_setup(REGEX_DEV_ID,
                                         REGEX_QP_ID, &qp_conf);
    if (ret < 0)
        return ret;

    return rte_regexdev_start(REGEX_DEV_ID);
}

/* 패킷 배치를 REE 엔진에 제출하고 결과 수집 */
static int process_packet_batch(struct rte_mbuf **pkts,
                                uint16_t nb_pkts,
                                uint32_t *match_flags)
{
    struct rte_regex_ops *ops[BATCH_SIZE];
    struct rte_regex_ops *results[BATCH_SIZE];
    uint16_t enqueued, dequeued;
    int i;

    /* 검색 오퍼레이션 생성 */
    for (i = 0; i < nb_pkts && i < BATCH_SIZE; i++) {
        ops[i] = rte_malloc(NULL, sizeof(struct rte_regex_ops), 0);
        if (!ops[i])
            return -ENOMEM;

        ops[i]->mbuf     = pkts[i];
        ops[i]->group_id0 = 0;      /* 규칙 그룹 ID */
        ops[i]->user_id   = i;      /* 패킷 식별자 */
        ops[i]->req_flags = 0;
    }

    /* 배치 제출 (enqueue) */
    enqueued = rte_regexdev_enqueue_burst(REGEX_DEV_ID,
                                           REGEX_QP_ID,
                                           ops, nb_pkts);

    /* 결과 수집 (dequeue) — 폴링 루프 */
    dequeued = 0;
    while (dequeued < enqueued) {
        uint16_t n = rte_regexdev_dequeue_burst(
                         REGEX_DEV_ID, REGEX_QP_ID,
                         results + dequeued,
                         enqueued - dequeued);
        dequeued += n;
    }

    /* 매칭 결과 처리 */
    for (i = 0; i < dequeued; i++) {
        uint16_t nb_matches = results[i]->nb_matches;
        uint32_t pkt_idx    = results[i]->user_id;

        if (nb_matches > 0) {
            match_flags[pkt_idx] = 1;

            for (uint16_t m = 0; m < nb_matches; m++) {
                struct rte_regexdev_match *match;
                match = &results[i]->matches[m];
                RTE_LOG(DEBUG, USER1,
                        "pkt[%u] match: rule=%u off=%u len=%u\n",
                        pkt_idx, match->rule_id,
                        match->start_offset, match->len);
            }
        } else {
            match_flags[pkt_idx] = 0;
        }
        rte_free(results[i]);
    }

    return dequeued;
}

Hyperscan + Intel QAT 가속

Hyperscan은 Intel이 개발한 고성능 정규식 매칭 라이브러리로, SIMD(SSE4.2/AVX2/AVX-512) 명령어를 활용한 멀티 패턴 매칭을 제공합니다. 전용 하드웨어가 아닌 CPU 기반이지만, 하드웨어 수준에 근접하는 성능을 달성합니다. Intel QAT(QuickAssist Technology)와 조합하면 암호 해제 + 정규식 매칭 파이프라인을 구성할 수 있습니다.

Hyperscan의 핵심 장점은 다음과 같습니다.

• 멀티 패턴 동시 매칭: 수만 개 패턴을 단일 패스(Single Pass)로 매칭합니다.
• SIMD 최적화: AVX-512 기반 DFA 시뮬레이션으로 코어당 수 Gbps 처리를 달성합니다.
• Chimera 모드: Hyperscan + PCRE 폴백을 결합하여 호환성과 성능을 모두 확보합니다.
• 사전 컴파일: 패턴 DB를 바이트코드로 사전 컴파일하여 런타임 오버헤드를 제거합니다.

Suricata에서 Hyperscan MPM을 활성화하는 설정 예제입니다.

# /etc/suricata/suricata.yaml — Hyperscan MPM 설정

# Multi-Pattern Matching 엔진 선택
mpm-algo: hs  # 'ac' (Aho-Corasick) 대신 'hs' (Hyperscan)

# 패턴 매칭 상세 설정
detect:
  profile: high       # high = 더 많은 메모리, 더 빠른 매칭
  sgh-mpm-context: full  # 시그니처 그룹별 독립 MPM 컨텍스트
  inspection-recursion-limit: 3000

# Hyperscan 관련 상세 설정
# Suricata 빌드 시 --enable-hyperscan 필요
# 의존성: libhs-dev (Intel Hyperscan 라이브러리)

# Intel QAT 암호 해제 가속 (AF_ALG 또는 OpenSSL QAT engine)
# TLS 복호화 → Hyperscan 매칭 파이프라인
app-layer:
  protocols:
    tls:
      enabled: yes
      detection-ports:
        dp: 443
      # QAT 가속 OpenSSL 엔진 사용 시 별도 설정 필요

# Suricata 빌드 시 Hyperscan 활성화
./configure --enable-hyperscan \
            --with-libhs-includes=/usr/include/hs \
            --with-libhs-libraries=/usr/lib/x86_64-linux-gnu

# Hyperscan 성능 벤치마크
# hsbench: Hyperscan 공식 벤치마크 도구
hsbench -e /path/to/patterns.db \
        -c /path/to/corpus/ \
        -T 8            # 8 스레드

# Intel QAT 디바이스 확인
lspci | grep "QuickAssist"
# 출력 예: 0000:6b:00.0 Co-processor: Intel Corporation
#          C62x Chipset QuickAssist Technology

# QAT 상태 확인
adf_ctl status
# 출력 예: qat_dev0 - type: c6xx, state: up

# QAT OpenSSL 엔진 설정 확인
openssl engine -t qatengine
# 출력 예: (qatengine) Reference implementation of QAT engine
#          [ available ]

Regex HW와 NGFW 파이프라인 통합 패턴

정규식 하드웨어 가속 엔진을 NGFW 파이프라인에 효율적으로 통합하려면 2단계 필터링 모델을 사용합니다. 모든 패킷을 하드웨어 정규식 엔진에 보내는 것은 비효율적이므로, 저비용 사전 필터(Pre-filter)로 후보를 먼저 선별하고, 후보 패킷만 정밀 매칭 엔진에 전달합니다.

이 2단계 모델의 핵심은 1단계에서 대부분의 정상 트래픽을 빠르게 통과시키고(95~99%), 의심 트래픽(1~5%)만 2단계 하드웨어 엔진으로 전달하는 것입니다.

• 블룸 필터 사전 필터: 시그니처에서 추출한 고정 문자열(Literal)로 블룸 필터를 구성합니다. 블룸 필터에 히트되지 않으면 해당 패킷은 어떤 시그니처와도 매칭되지 않으므로 즉시 통과(PASS)합니다.
• 위양성 처리: 블룸 필터는 위양성(False Positive)이 존재하므로, 1단계를 통과한 패킷이 2단계에서 실제로 매칭되지 않을 수 있습니다. 이는 정상적인 동작이며, 블룸 필터 크기와 해시 함수 수를 조정하여 위양성 비율을 0.1~1% 수준으로 관리합니다.
• XDP/TC 기반 인라인 통합: 1단계 사전 필터를 XDP 또는 TC BPF 프로그램에 구현하면, 커널 네트워크 스택에 진입하기 전에 필터링할 수 있습니다.
• NFQUEUE 기반 통합: Netfilter의 NFQUEUE를 통해 패킷을 사용자 공간으로 전달하고, regex HW 엔진으로 검사한 후 NF_ACCEPT 또는 NF_DROP 판정을 반환합니다.

위 다이어그램은 2단계 DPI 파이프라인의 전체 흐름을 보여줍니다. 1단계 사전 필터에서 95~99%의 정상 트래픽을 즉시 통과시키고, 나머지 1~5%의 의심 트래픽만 2단계 Regex HW 엔진으로 전달합니다. 2단계에서도 위양성 패킷은 PASS로 처리되며, 실제 시그니처 매칭이 확인된 패킷만 DROP/LOG/ALERT 정책을 적용합니다.

상용 NGFW HW 아키텍처

상용 NGFW는 암호화·DPI 가속을 위해 크게 두 가지 하드웨어 처리 모델을 사용합니다:

대부분의 상용 NGFW는 두 모델을 혼합(Hybrid)하여 사용합니다. 아래 표는 벤더별 주요 기능의 inline/lookaside 분류입니다:

암호화 오프로드 아키텍처 3분류

앞선 표에서 lookaside를 단일 카테고리로 분류했지만, 실제 구현을 살펴보면 lookaside 방식은 가속기의 물리적 위치와 버스 토폴로지에 따라 크게 두 가지로 나뉩니다. CPU중심 룩어사이드(CPU-Centric Lookaside)는 PCIe 카드 형태의 외장 가속기를, SoC중심 룩어사이드(SoC-Centric Lookaside)는 SoC 다이 내장 크립토 엔진을 사용합니다. 여기에 데이터 경로 자체에 암호화를 삽입하는 인라인(Inline) 방식까지 포함하면, 암호화 오프로드는 3분류로 정리됩니다.

각 아키텍처의 핵심 차이는 패킷 데이터가 암호화 엔진에 도달하는 경로와 결과가 반환되는 지연 시간입니다. 기존 전용 크립토 가속기 섹션의 HW 스펙표와 함께 참조하면 전체 그림을 파악할 수 있습니다.

CPU중심 룩어사이드(CPU-Centric Lookaside)

CPU중심 룩어사이드는 CPU가 호스트 메모리에 있는 패킷 데이터를 PCIe 버스를 통해 외장 가속기 카드에 전송하고, 가속기가 처리한 결과를 다시 PCIe DMA로 돌려받는 모델입니다. CPU가 submission ring에 작업을 큐잉하면, 가속기가 비동기로 처리한 뒤 completion ring을 통해 완료를 통보합니다.

대표 하드웨어:

• Intel QAT 8970 (PCIe 카드) — 200 Gbps 대칭키, 140K RSA-2048 ops/s. qat_c62x 드라이버. 서버/어플라이언스용 대용량 SSL 프록시에 적합
• Intel QAT 4xxx (4th/5th Gen Xeon 내장) — 100 Gbps. SPR 이후 CPU에 통합되었으나, PCIe 도메인의 별도 디바이스로 노출되어 여전히 CPU중심 룩어사이드 모델
• Marvell NITROX V (PCIe 카드) — 100 Gbps, 최대 64 VF(SR-IOV) 지원. nitrox 드라이버로 커널 crypto API에 등록

커널 crypto API에 등록된 가속기의 우선순위 확인:

# 등록된 암호화 알고리즘과 우선순위 확인
cat /proc/crypto | grep -A4 "name.*gcm(aes)"
# 출력 예시: driver = qat_aes_gcm, priority = 4001
# 우선순위가 높을수록 먼저 선택됨 (SW fallback은 보통 100~200)

# QAT 디바이스 상태 확인
cat /sys/kernel/debug/qat_4xxx_0000:6b:00.0/fw_counters

/* CPU중심 룩어사이드: 비동기 콜백 패턴 */
struct aead_request *req = aead_request_alloc(tfm, GFP_ATOMIC);
aead_request_set_callback(req, CRYPTO_TFM_REQ_MAY_BACKLOG,
                          crypto_done_callback, &result);
aead_request_set_crypt(req, src_sg, dst_sg, payload_len, iv);
aead_request_set_ad(req, assoclen);

ret = crypto_aead_encrypt(req);
if (ret == -EINPROGRESS || ret == -EBUSY) {
    /* 가속기가 비동기 처리 중 — completion 대기 */
    wait_for_completion(&result.completion);
    ret = result.err;
}
/* QAT: PCIe DMA 왕복 지연 ~10-50μs 포함 */

SoC중심 룩어사이드(SoC-Centric Lookaside)

SoC중심 룩어사이드는 크립토 엔진이 SoC 다이 내부에 통합되어 있으며, CPU와 내부 버스(AXI/AHB/ACE)로 직접 연결됩니다. PCIe를 거치지 않으므로 DMA 왕복 지연이 크게 줄어들고, 별도 전원·슬롯이 필요 없어 임베디드·네트워크 장비에 널리 사용됩니다. CPU가 Job Ring(또는 Command Ring)에 작업을 큐잉하면, 내장 크립토 엔진이 내부 버스를 통해 메모리에서 직접 데이터를 읽어 처리합니다.

대표 하드웨어:

• NXP CAAM (Cryptographic Acceleration and Assurance Module) — NXP Layerscape/i.MX SoC에 내장. Job Ring 기반 비동기 처리, 최대 4 JR. Linux 드라이버: caam (drivers/crypto/caam/)
• Marvell OCTEON CPT (Crypto Processing Thread) — OCTEON TX2/CN10K에 내장. 최대 100 Gbps 대칭키. octeontx2-cpt 드라이버
• Broadcom SPU (Security Processing Unit) — BCM58xxx/Memory Stingray SoC. bcm_crypto_spu 드라이버
• ARM CryptoCell — ARM TrustZone 연동 보안 코프로세서, 1-5 Gbps. ccree 드라이버. 상세 스펙은 크립토 가속기 비교표 참조

Device Tree 바인딩 예시 (NXP CAAM):

/* NXP Layerscape SoC — CAAM Device Tree 바인딩 */
crypto@1700000 {
    compatible = "fsl,sec-v5.4", "fsl,sec-v5.0",
                 "fsl,sec-v4.0";
    reg = <0x0 0x1700000 0x0 0x100000>;
    interrupts = <GIC_SPI 75 IRQ_TYPE_LEVEL_HIGH>;
    #address-cells = <1>;
    #size-cells = <1>;
    ranges = <0x0 0x0 0x1700000 0x100000>;

    /* Job Ring 0 */
    jr0: jr@10000 {
        compatible = "fsl,sec-v5.4-job-ring",
                     "fsl,sec-v4.0-job-ring";
        reg = <0x10000 0x10000>;
        interrupts = <GIC_SPI 71 IRQ_TYPE_LEVEL_HIGH>;
    };
    /* Job Ring 1 */
    jr1: jr@20000 {
        compatible = "fsl,sec-v5.4-job-ring";
        reg = <0x20000 0x10000>;
        interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>;
    };
};

인라인 암호화(Inline Crypto)

인라인 암호화는 가속기가 네트워크 데이터 경로(data path) 자체에 위치하여, 패킷이 NIC/SmartNIC을 통과하는 과정에서 암호화·복호화가 수행됩니다. CPU는 암호 키 설정과 SA(Security Association) 구성만 담당하고, 실제 패킷 데이터에는 전혀 관여하지 않습니다. IPSec, MACsec, kTLS(커널 TLS) 3가지 프로토콜이 인라인 오프로드의 대표적 사례입니다.

대표 하드웨어:

• NVIDIA (Mellanox) ConnectX-6 Dx / ConnectX-7 — IPSec inline (200 Gbps), MACsec, kTLS offload. mlx5_core 드라이버. xfrm offload + TC flower 연동
• Intel E810 (Colville) — IPSec inline offload (100 Gbps). ice 드라이버. ethtool -K eth0 esp-hw-offload on으로 활성화
• AMD (Pensando) DSC-200 — SmartNIC/DPU, IPSec + kTLS inline. P4 프로그래머블 파이프라인에 crypto 엔진 통합

인라인 IPSec 오프로드 설정 확인(상세는 kTLS 오프로드 섹션 참조):

# NIC의 inline crypto 기능 확인
ethtool -k eth0 | grep -E "esp-hw-offload|tls-hw"
# esp-hw-offload: on        ← IPSec inline 지원
# tls-hw-tx-offload: on     ← kTLS TX inline 지원
# tls-hw-rx-offload: on     ← kTLS RX inline 지원

# xfrm (IPSec) offload 설정 — SA에 offload 플래그 추가
ip xfrm state add src 10.0.0.1 dst 10.0.0.2 \
    proto esp spi 0x100 reqid 1 mode tunnel \
    aead "rfc4106(gcm(aes))" 0x$(xxd -l 20 -p /dev/urandom) 128 \
    offload dev eth0 dir out    # ← inline offload 핵심 옵션

# offload 상태 확인
ip xfrm state show | grep -A2 offload

3종 아키텍처 종합 비교

하드웨어별 아키텍처 분류 상세:

리눅스 커널 Crypto API 매핑

리눅스 커널의 다양한 암호화 서브시스템은 3종 아키텍처를 각각 다른 경로로 활용합니다. 아래 표는 주요 서브시스템별 매핑을 보여줍니다:

커널 crypto API의 우선순위 기반 자동 선택(fallback chain):

# /proc/crypto에서 동일 알고리즘의 우선순위 확인
# 우선순위가 높은 드라이버가 자동 선택됨
$ grep -B1 -A5 "gcm(aes)" /proc/crypto

name         : gcm(aes)
driver       : qat_aes_gcm           # ← QAT 가속기 (CPU중심 Lookaside)
priority     : 4001                    # ← 최우선
async        : yes

name         : gcm(aes)
driver       : caam-gcm-aes           # ← CAAM (SoC중심 Lookaside)
priority     : 3000
async        : yes

name         : gcm(aes)
driver       : generic-gcm-aesni      # ← CPU AES-NI (SW fallback)
priority     : 400
async        : no

# Fallback chain: QAT(4001) → CAAM(3000) → AES-NI(400) → generic(100)
# 가속기 장애 시 자동으로 다음 우선순위 드라이버로 전환

암호화 완료 모델: 동기·비동기·폴링

커널 crypto API에서 암호화 요청이 HW 가속기에 제출된 뒤 결과를 수신하는 방식은 크게 3가지로 나뉩니다: 동기(Synchronous), 비동기 인터럽트(Asynchronous Interrupt), 비동기 폴링(Asynchronous Polling). 각 모델은 지연 시간, CPU 활용률, 처리량 특성이 근본적으로 다르며, NGFW의 성능 프로파일을 결정하는 핵심 요소입니다.

동기 처리(Synchronous)

동기 모델에서 CPU는 암호화 함수를 호출한 뒤 결과가 반환될 때까지 블로킹됩니다. CPU 자체의 AES-NI/ARMv8-CE 명령어로 처리하는 경우가 대표적이며, 함수 호출과 반환이 동일 컨텍스트에서 완료됩니다.

/* 동기(Synchronous) 처리 — CPU 명령어(AES-NI) 직접 실행 */
struct skcipher_request *req = skcipher_request_alloc(tfm, GFP_KERNEL);
skcipher_request_set_crypt(req, src_sg, dst_sg, len, iv);

/* 콜백 없이 직접 호출 — 반환 시 이미 완료 */
ret = crypto_skcipher_encrypt(req);
/* ret == 0: 즉시 완료 (동기)
 * CPU AES-NI의 경우 /proc/crypto에서 async: no 표시 */

if (ret == 0) {
    /* 암호화 완료 — 결과가 dst_sg에 이미 기록됨 */
    process_encrypted_packet(dst_sg);
}
skcipher_request_free(req);

비동기 인터럽트 처리(Asynchronous Interrupt-Driven)

비동기 인터럽트 모델은 커널 crypto API에서 가장 일반적인 HW 가속기 활용 패턴입니다. CPU가 요청을 가속기의 submission ring에 큐잉하면 즉시 반환되고, 가속기가 처리를 완료하면 인터럽트(IRQ)를 발생시켜 등록된 콜백 함수를 호출합니다.

커널 crypto API에서 비동기 요청의 반환값 의미와 콜백 처리 흐름:

/*
 * crypto API 반환값 — 완료 모델을 결정하는 핵심
 *
 *  0            : 동기 완료 — 결과가 이미 준비됨
 * -EINPROGRESS  : 비동기 처리 시작됨 — 콜백으로 완료 통보 예정
 * -EBUSY        : 백로그(backlog) 큐에 진입 — 큐 공간 확보 후 처리 예정
 * -ENOSPC       : 큐 가득 참(백로그 미허용 시) — 호출자가 재시도해야 함
 * 기타 음수     : 오류 (키 설정 오류, 메모리 부족 등)
 */

/* ── 비동기 콜백 구조체 ── */
struct crypto_async_result {
    struct completion completion;   /* wait_for_completion() 대상 */
    int err;                        /* 콜백에서 설정되는 최종 에러 코드 */
};

/* ── 콜백 함수 — 가속기 인터럽트 핸들러에서 호출됨 ── */
static void crypto_op_complete(void *data, int err)
{
    struct crypto_async_result *result = data;
    /*
     * err == 0        : 암호화 성공
     * err == -EINPROGRESS : 백로그에서 꺼내어 처리 시작
     *                       (CRYPTO_TFM_REQ_MAY_BACKLOG 설정 시)
     * err < 0 (기타)  : HW 오류
     */
    if (err == -EINPROGRESS)
        return;  /* 아직 완료 아님 — 실제 완료 시 다시 호출됨 */

    result->err = err;
    complete(&result->completion);  /* 대기 중인 스레드 깨움 */
}

/* ── 요청 제출 — CRYPTO_TFM_REQ_MAY_BACKLOG 플래그 상세 ── */
struct aead_request *req = aead_request_alloc(tfm, GFP_ATOMIC);
aead_request_set_callback(req,
    CRYPTO_TFM_REQ_MAY_BACKLOG |   /* 큐 가득 차도 백로그 허용 */
    CRYPTO_TFM_REQ_MAY_SLEEP,      /* 콜백에서 sleep 가능 (프로세스 컨텍스트) */
    crypto_op_complete, &result);
aead_request_set_crypt(req, src_sg, dst_sg, payload_len, iv);
aead_request_set_ad(req, assoclen);

ret = crypto_aead_encrypt(req);
switch (ret) {
case 0:
    /* 동기 완료 — SW fallback이 선택된 경우 또는
     * 가속기가 즉시 처리 완료한 경우 */
    process_result(req);
    break;

case -EINPROGRESS:
    /* 비동기 처리 시작 — 가속기가 DMA로 데이터 전송 중
     * 완료 시 crypto_op_complete() 콜백 호출됨 */
    break;

case -EBUSY:
    /* 가속기 큐 가득 참 + 백로그에 진입
     * CRYPTO_TFM_REQ_MAY_BACKLOG 덕분에 거부되지 않음
     * 콜백이 두 번 호출됨:
     *   1차: err=-EINPROGRESS (백로그→실제 큐 이동 시)
     *   2차: err=0 (처리 완료 시) */
    break;

default:
    /* 오류 — 키 미설정, 메모리 부족, HW 장애 등 */
    pr_err("crypto op failed: %d\n", ret);
    break;
}

백로그(Backlog) 큐 동작 상세:

┌─────────────────────────────────────────────────────────┐
│              가속기 Submission Ring (크기: 512)            │
│  [req1] [req2] [req3] ... [req510] [req511] [req512]    │
│  ← 가득 참 (new request 도착)                            │
└─────────────────────────────────────────────────────────┘
                         │
    ┌────────────────────┼────────────────────┐
    │ MAY_BACKLOG 미설정  │  MAY_BACKLOG 설정   │
    ▼                    │                    ▼
 -ENOSPC 반환            │              -EBUSY 반환
 (호출자가 재시도)        │         (백로그 큐에 진입)
                         │                    │
                         │    ┌───────────────┘
                         │    ▼
                         │  Backlog Queue
                         │  [req513] [req514] ...
                         │    │
                         │    │  Ring 슬롯 빌 때
                         │    ▼
                         │  콜백(err=-EINPROGRESS)
                         │  → 실제 큐로 이동
                         │    │
                         │    │  HW 처리 완료
                         │    ▼
                         │  콜백(err=0)
                         │  → 최종 완료
                         └────────────────────

비동기 폴링 처리(Asynchronous Polling)

비동기 폴링 모델에서는 인터럽트 대신 CPU가 주기적으로 completion ring(또는 상태 레지스터)을 직접 확인합니다. 인터럽트 발생·처리·컨텍스트 전환 오버헤드를 제거하여 초저지연을 달성할 수 있지만, 폴링 동안 CPU 사이클을 소모합니다.

커널 6.0+에서 도입된 crypto_engine 폴링 모드와 DPDK 환경의 busy-polling이 대표적입니다:

커널 crypto_engine 폴링 모드 — 커널 6.0+에서 struct crypto_engine은 가속기 드라이버에 폴링 기반 완료 처리를 지원합니다:

/*
 * crypto_engine 폴링 모드 (커널 6.0+)
 * drivers/crypto/crypto_engine.c
 *
 * 기본 인터럽트 모드 대비 폴링 모드 전환 조건:
 * 1. 고처리량 시나리오 (인터럽트 스톰 방지)
 * 2. 초저지연 요구 (IRQ 컨텍스트 전환 제거)
 */

/* ── 드라이버에서 폴링 모드 지원 등록 ── */
struct crypto_engine *engine;
engine = crypto_engine_alloc_init(dev, true);  /* rt=true: 실시간 우선순위 */

/* 폴링 기반 완료 처리 — 전용 kthread가 CQ를 확인 */
static int hw_accel_poll_completions(struct crypto_engine *engine)
{
    struct hw_completion_ring *cq = engine->priv;
    int completed = 0;

    /* completion ring의 유효한 엔트리를 순회 */
    while (cq->head != cq->tail) {
        struct crypto_async_request *req;
        struct hw_cq_entry *entry = &cq->entries[cq->head];

        /* 완료 여부 확인 (HW가 done 비트 설정) */
        if (!(READ_ONCE(entry->flags) & HW_CQ_DONE))
            break;

        req = entry->async_req;
        /* DMA 매핑 해제 */
        dma_unmap_sg(dev, req->src, sg_nents(req->src),
                     DMA_BIDIRECTIONAL);

        /* 콜백 호출 — 인터럽트 컨텍스트가 아닌
         * kthread 컨텍스트에서 실행 */
        crypto_finalize_request(engine, req, 0);

        cq->head = (cq->head + 1) % cq->ring_size;
        completed++;
    }
    return completed;
}

/*
 * 인터럽트 vs 폴링 전환 (적응형 모드)
 * 처리량이 임계치를 초과하면 자동으로 폴링 전환
 */
static irqreturn_t hw_accel_irq_handler(int irq, void *data)
{
    struct hw_accel_dev *hdev = data;

    if (hdev->completions_per_sec > POLL_THRESHOLD) {
        /* 고처리량 → 인터럽트 비활성화 + 폴링 모드 전환 */
        disable_irq_nosync(irq);
        hdev->polling = true;
        /* kthread가 폴링 루프 시작 */
        wake_up_process(hdev->poll_thread);
        return IRQ_HANDLED;
    }
    /* 일반 모드 — 인터럽트 기반 완료 */
    return hw_accel_process_irq(hdev);
}

DPDK / 유저스페이스 busy-polling — NGFW에서 DPDK 기반 데이터 플레인(VPP, Suricata AF_XDP)을 사용할 경우:

/*
 * DPDK cryptodev 폴링 모드 — 유저스페이스 busy-polling
 * rte_cryptodev_dequeue_burst()로 완료된 작업 수집
 */

/* 1. 암호화 요청 배치 제출 (enqueue) */
uint16_t enqueued = rte_cryptodev_enqueue_burst(
    cdev_id,        /* crypto device ID */
    qp_id,          /* queue pair */
    crypto_ops,     /* 요청 배열 */
    nb_ops          /* 배치 크기 (32-256) */
);

/* 2. busy-polling으로 완료 수집 (dequeue) */
uint16_t dequeued;
do {
    dequeued = rte_cryptodev_dequeue_burst(
        cdev_id, qp_id,
        completed_ops,  /* 완료된 요청 배열 */
        MAX_BURST       /* 최대 수집 수 */
    );
    /*
     * dequeued == 0: 아직 완료된 작업 없음 → 재폴링
     * 인터럽트·컨텍스트 전환 없이 즉시 재확인
     * → 지연 최소화, 단 CPU 100% 사용
     */
} while (dequeued == 0);

/* 3. 완료된 작업 처리 */
for (int i = 0; i < dequeued; i++) {
    if (completed_ops[i]->status ==
        RTE_CRYPTO_OP_STATUS_SUCCESS) {
        /* 암호화 완료 — 다음 파이프라인 단계로 전달 */
        forward_packet(completed_ops[i]->sym->m_dst);
    }
}

완료 모델 종합 비교

적응형 인터럽트 병합과 하이브리드 폴링

실무 NGFW에서는 순수 인터럽트나 순수 폴링이 아닌, 트래픽 부하에 따라 동적으로 전환하는 적응형(adaptive) 모델을 사용합니다. 리눅스 커널 NAPI(New API)가 네트워크 드라이버에서 사용하는 것과 동일한 원리입니다:

                     트래픽 부하
        낮음 ◀──────────────────────────▶ 높음
        ┌───────────┬───────────┬──────────────┐
 완료   │ 인터럽트   │ 인터럽트   │    폴링      │
 감지   │ (즉시)     │ (병합)    │ (busy-poll)  │
 방식   │           │           │              │
        ├───────────┼───────────┼──────────────┤
 IRQ    │ 요청당     │ N개 묶음  │   비활성화    │
 빈도   │ 1회       │ (coalesce)│   (0회)      │
        ├───────────┼───────────┼──────────────┤
 CPU    │ 최소       │ 낮음      │   전용 코어   │
 사용   │           │           │   100%       │
        ├───────────┼───────────┼──────────────┤
 지연   │ ~5μs      │ ~10-30μs  │   <1μs       │
        │           │ (병합     │   (즉시      │
        │           │  대기시간) │    감지)     │
        └───────────┴───────────┴──────────────┘

        ◀─ 유휴 시    적응형 전환 ──────▶ 포화 시

/*
 * 적응형 인터럽트/폴링 전환 — NAPI식 crypto 완료 처리
 * 고처리량 시 인터럽트 스톰을 방지하고 배치 처리 효율 극대화
 */
#define POLL_BUDGET      64    /* 한 번의 폴링에서 최대 처리 수 */
#define IRQ_TO_POLL_THRESH  1000  /* IRQ/초 임계치 → 폴링 전환 */
#define POLL_TO_IRQ_THRESH  100   /* 폴링 공회전 → IRQ 복귀 */

/* ── 인터럽트 핸들러: 고부하 감지 시 폴링 전환 ── */
static irqreturn_t crypto_irq_handler(int irq, void *data)
{
    struct crypto_hw_queue *q = data;

    q->irq_count++;

    if (q->irq_count > IRQ_TO_POLL_THRESH) {
        /* 인터럽트 빈도 과다 → 폴링 모드 전환 */
        disable_irq_nosync(irq);
        q->mode = CRYPTO_MODE_POLL;
        napi_schedule(&q->napi);   /* 폴링 스케줄링 */
        return IRQ_HANDLED;
    }

    /* 일반 모드: 개별 완료 처리 */
    crypto_process_completions(q, 1);
    return IRQ_HANDLED;
}

/* ── NAPI식 폴링 핸들러 ── */
static int crypto_napi_poll(struct napi_struct *napi, int budget)
{
    struct crypto_hw_queue *q =
        container_of(napi, struct crypto_hw_queue, napi);
    int completed = 0;

    /* completion ring에서 완료된 항목 배치 수집 */
    completed = crypto_poll_completions(q, budget);

    if (completed < budget) {
        /*
         * 배치 미달 → 트래픽 감소 감지
         * 폴링 종료 + 인터럽트 복원
         */
        q->idle_polls++;
        if (q->idle_polls > POLL_TO_IRQ_THRESH) {
            napi_complete(napi);
            q->mode = CRYPTO_MODE_IRQ;
            q->irq_count = 0;
            q->idle_polls = 0;
            enable_irq(q->irq_num);  /* 인터럽트 복원 */
        }
    } else {
        q->idle_polls = 0;  /* 배치 꽉 참 → 계속 폴링 */
    }
    return completed;
}

인터럽트 병합(Interrupt Coalescing) 설정 — QAT 가속기 예시:

# QAT 인터럽트 병합 설정
# /etc/sysconfig/qat 또는 sysfs 경로

# 병합 타이머: N μs 동안 완료를 모아서 단일 IRQ 발생
echo 10 > /sys/kernel/debug/qat_4xxx_0000:6b:00.0/irq_coal_timer_ns
# 10μs 간격 → 초당 최대 100K IRQ (vs 병합 없이 수백만)

# 병합 카운트: N개 완료마다 IRQ 1회
echo 32 > /sys/kernel/debug/qat_4xxx_0000:6b:00.0/irq_coal_count
# 32개 완료 묶음 → IRQ 횟수 1/32로 감소

# 현재 모드 확인
cat /sys/kernel/debug/qat_4xxx_0000:6b:00.0/irq_mode
# adaptive / timer / count / poll

# ethtool로 NIC crypto 인터럽트 병합 설정 (ConnectX-7)
ethtool -C eth0 rx-usecs 10 tx-usecs 10
# 10μs 간격으로 RX/TX 인터럽트 병합

아키텍처 선택 가이드

시나리오별로 최적의 암호화 오프로드 아키텍처를 선택하는 기준:

하드웨어 이벤트 스케줄러 (Intel DLB / Marvell SSO)

NGFW 데이터 플레인에서 수백만 플로우를 다수의 CPU 코어에 효율적으로 분배하는 것은 핵심 과제입니다. RSS(Receive Side Scaling)는 해시 기반 정적 분배만 가능하여 코어 간 부하 불균형이 발생하고, 소프트웨어 큐 관리는 락 경합과 캐시 바운싱 오버헤드를 유발합니다. 하드웨어 이벤트 스케줄러(Hardware Event Scheduler)는 이 문제를 전용 ASIC/SoC 블록으로 해결합니다.

대표적인 HW 이벤트 스케줄러로 Intel의 DLB(Dynamic Load Balancer)와 Marvell의 SSO(Schedule/Synchronize/Order)가 있으며, 둘 다 원자적 플로우 스케줄링, 순서 보장, 동적 부하 분산을 하드웨어 수준에서 제공합니다.

이벤트 스케줄러 핵심 개념

HW 이벤트 스케줄러는 패킷을 직접 전달하지 않고, 이벤트(Event) 단위로 작업을 추상화합니다. 하나의 이벤트는 패킷 도착, 타이머 만료, 크립토 완료 등 다양한 소스에서 발생하며, 스케줄러가 이를 워커 코어(Worker Core)에 분배합니다.

3종 스케줄링 모드가 NGFW 파이프라인에서 각각 다른 단계에 적용됩니다:

Intel DLB (Dynamic Load Balancer)

Intel DLB(이전 명칭 HQM — Hardware Queue Manager)는 4th Gen Xeon(SPR) 이후 CPU에 내장된 하드웨어 이벤트 스케줄러입니다. PCIe 디바이스로도 출시되었으며(DLB 2.0/2.5), DPDK eventdev 라이브러리를 통해 VPP, DPDK 기반 NGFW, Open vSwitch 등에서 활용됩니다.

DLB 핵심 사양:

DLB의 핵심 구성 요소:

• QID(Queue ID) — 논리적 이벤트 큐. 하나의 QID에 스케줄링 타입(atomic/ordered/parallel)과 우선순위를 설정합니다. NGFW에서는 파이프라인 단계별(방화벽→IPS→암호화) QID를 할당합니다
• CQ(Consumer Queue) — 워커 코어가 이벤트를 수신하는 큐. 각 코어에 1개 CQ를 바인딩하고, 폴링 또는 인터럽트로 이벤트를 가져옵니다
• PP(Producer Port) — 이벤트 소스(NIC RX, crypto 완료 등)가 이벤트를 제출하는 포트
• Credit — 흐름 제어 메커니즘. Producer는 이벤트 제출 시 credit을 소모하고, Consumer가 처리 완료 후 반환합니다. Credit 고갈 시 자동 배압(backpressure) 발생
• Directed Port/Queue — 스케줄링 없이 특정 CQ에 직접 전달하는 1:1 경로. 파이프라인 단계 간 명시적 전달에 사용

DPDK eventdev를 통한 DLB 설정과 NGFW 파이프라인 구성:

/*
 * DPDK eventdev API로 DLB 기반 NGFW 파이프라인 구성
 * rte_event_dev → rte_event_queue → rte_event_port 매핑
 */
#include <rte_eventdev.h>
#include <rte_event_eth_rx_adapter.h>
#include <rte_event_crypto_adapter.h>

/* 1. DLB eventdev 초기화 */
struct rte_event_dev_config dev_conf = {
    .nb_event_queues = 4,        /* QID 4개 (FW/IPS/Crypto/TX) */
    .nb_event_ports = 8,         /* 워커 코어 8개 */
    .nb_events_limit = 4096,     /* 최대 동시 이벤트 수 */
    .nb_event_queue_flows = 1024,/* 플로우 해시 엔트리 수 */
    .nb_event_port_dequeue_depth = 32,
    .nb_event_port_enqueue_depth = 32,
};
rte_event_dev_configure(evdev_id, &dev_conf);

/* 2. 파이프라인 단계별 QID 설정 */
struct rte_event_queue_conf q_conf;

/* QID 0: 방화벽 (Atomic — conntrack 상태 보호) */
q_conf.schedule_type = RTE_SCHED_TYPE_ATOMIC;
q_conf.priority = RTE_EVENT_DEV_PRIORITY_HIGHEST;
q_conf.nb_atomic_flows = 1024;   /* 동시 추적 플로우 수 */
rte_event_queue_setup(evdev_id, 0, &q_conf);

/* QID 1: IPSec 암복호화 (Ordered — 순서 보장 + 병렬) */
q_conf.schedule_type = RTE_SCHED_TYPE_ORDERED;
q_conf.priority = RTE_EVENT_DEV_PRIORITY_NORMAL;
rte_event_queue_setup(evdev_id, 1, &q_conf);

/* QID 2: IPS/DPI (Parallel — 최대 처리량) */
q_conf.schedule_type = RTE_SCHED_TYPE_PARALLEL;
rte_event_queue_setup(evdev_id, 2, &q_conf);

/* QID 3: TX (Directed — 특정 TX 코어로 직접 전달) */
/* Directed는 별도 API로 설정 */

/* 3. 워커 포트 설정 — 각 코어에 CQ 바인딩 */
struct rte_event_port_conf p_conf = {
    .dequeue_depth = 32,
    .enqueue_depth = 32,
    .new_event_threshold = 128,  /* credit 기반 배압 임계치 */
};
for (int i = 0; i < 8; i++) {
    rte_event_port_setup(evdev_id, i, &p_conf);
    /* 포트 i → QID 0,1,2 매핑 (어떤 단계든 처리 가능) */
    rte_event_port_link(evdev_id, i, queues, priorities, 3);
}

/* 4. NIC RX → DLB 이벤트 어댑터 연결 */
rte_event_eth_rx_adapter_create(rx_adapter_id, evdev_id, &p_conf);
rte_event_eth_rx_adapter_queue_add(rx_adapter_id,
    eth_port_id, -1, /* 모든 RX 큐 */
    &(struct rte_event_eth_rx_adapter_queue_conf){
        .ev.queue_id = 0,    /* 첫 단계: FW QID */
        .ev.sched_type = RTE_SCHED_TYPE_ATOMIC,
        .ev.flow_id = 0,     /* RSS 해시를 flow_id로 사용 */
    });
rte_event_eth_rx_adapter_start(rx_adapter_id);

/* 5. 워커 루프 — 이벤트 수신·처리·전달 */
static void worker_loop(uint8_t port_id)
{
    struct rte_event events[32];
    while (!quit) {
        uint16_t nb = rte_event_dequeue_burst(
            evdev_id, port_id, events, 32, 0 /* no wait */);

        for (int i = 0; i < nb; i++) {
            struct rte_mbuf *pkt = events[i].mbuf;
            uint8_t cur_qid = events[i].queue_id;

            switch (cur_qid) {
            case 0: /* 방화벽 단계 — Atomic */
                if (firewall_check(pkt) == FW_PASS) {
                    /* 다음 단계(Crypto)로 전달 */
                    events[i].queue_id = 1;
                    events[i].op = RTE_EVENT_OP_FORWARD;
                } else {
                    rte_pktmbuf_free(pkt);
                    events[i].op = RTE_EVENT_OP_RELEASE;
                }
                break;

            case 1: /* IPSec 단계 — Ordered */
                ipsec_process(pkt);
                events[i].queue_id = 2;
                events[i].op = RTE_EVENT_OP_FORWARD;
                /* DLB가 자동으로 원래 순서 복원 */
                break;

            case 2: /* IPS/DPI 단계 — Parallel */
                ips_inspect(pkt);
                /* TX로 직접 전송 */
                rte_eth_tx_burst(tx_port, 0, &pkt, 1);
                events[i].op = RTE_EVENT_OP_RELEASE;
                break;
            }
        }
        rte_event_enqueue_burst(evdev_id, port_id, events, nb);
    }
}

# DLB 디바이스 확인
lspci | grep -i "dynamic load balancer"
# 6b:00.0 System peripheral: Intel Corporation
#         Dynamic Load Balancer (DLB) [8086:2710]

# 커널 드라이버 로드
modprobe dlb2
ls /dev/dlb*    # /dev/dlb0, /dev/dlb1, ...

# sysfs에서 DLB 리소스 확인
cat /sys/class/dlb2/dlb0/total_resources
# num_sched_domains: 32
# num_ldb_queues: 96
# num_ldb_ports: 64
# num_dir_ports: 96
# num_ldb_credits: 16384

# DPDK에서 DLB eventdev 바인딩
dpdk-devbind.py -b vfio-pci 0000:6b:00.0
# EAL 파라미터
--vdev=event_dlb2 --allow=0000:6b:00.0

Marvell OCTEON SSO (Schedule/Synchronize/Order)

Marvell OCTEON SSO는 OCTEON TX2/CN10K SoC에 내장된 하드웨어 이벤트 스케줄러입니다. Intel DLB와 유사한 기능을 제공하지만, SoC 내부의 모든 HW 가속기(크립토, 정규식, 압축)와 내부 버스로 직접 연동되는 것이 핵심 차이입니다. 패킷이 NIC에서 수신되면 SSO를 거쳐 CPU 코어에 분배되고, 크립토 처리 완료 후 다시 SSO로 돌아와 다음 단계 코어로 전달됩니다.

SSO 핵심 사양 (CN10K 기준):

SSO의 DLB 대비 핵심 차별점:

• HW 가속기 직접 연동: CPT(크립토), REE(정규식), ZIP(압축) 완료 시 자동으로 SSO 이벤트가 생성됩니다. DLB는 CPU가 가속기 완료를 확인한 뒤 이벤트를 재제출해야 하지만, SSO는 CPU 개입 없이 파이프라인이 진행됩니다
• WQE(Work Queue Entry): 패킷 메타데이터와 처리 컨텍스트를 포함하는 HW 구조체. NIC(RPM)이 패킷 수신 시 자동 생성하여 SSO에 제출합니다
• SWTAG(Software Tag Switch): 워커가 처리 중 태그 타입을 동적으로 변경할 수 있습니다. 예: conntrack 조회 시 Atomic → 패턴 매칭 시 Ordered로 전환
• TIM(Timer Wheel): HW 타이머가 만료되면 SSO 이벤트로 자동 전환. 세션 타임아웃 처리에 CPU 타이머 인터럽트 불필요

SSO를 활용한 NGFW 이벤트 드리븐 파이프라인:

/*
 * OCTEON CN10K SSO 기반 NGFW 파이프라인
 * DPDK eventdev API (event_cnxk 드라이버)
 *
 * 파이프라인: NIC RX → [SSO] → FW(Atomic) → [SSO] →
 *            CPT(Crypto) → [SSO] → IPS(Ordered) → TX
 */

/* 1. SSO 이벤트 수신 — MMIO GET_WORK */
static void sso_worker_loop(uint8_t port_id)
{
    struct rte_event ev;
    while (!quit) {
        /* SSO에서 이벤트 수신 (HW 폴링, ~10ns 지연) */
        if (rte_event_dequeue_burst(evdev_id, port_id,
                                     &ev, 1, 0) == 0)
            continue;

        struct rte_mbuf *pkt = ev.mbuf;
        uint32_t tag = ev.flow_id;  /* 플로우 해시 */

        switch (ev.queue_id) {
        case SSO_GRP_FIREWALL:  /* Atomic 모드 */
            /*
             * 동일 tag(flow)의 이벤트는 이 코어에서만 처리됨
             * → conntrack 조회/갱신에 락 불필요!
             */
            if (conntrack_lookup(tag, pkt) == CT_NEW) {
                conntrack_insert(tag, pkt);  /* lock-free */
            }
            if (!acl_check(pkt)) {
                rte_pktmbuf_free(pkt);
                ev.op = RTE_EVENT_OP_RELEASE;
                break;
            }

            /* IPSec 필요 시 → CPT(크립토)로 전달 */
            if (needs_ipsec(pkt)) {
                /*
                 * SSO → CPT 직접 전달 (CPU 미개입)
                 * CPT 완료 시 자동으로 SSO 이벤트 재생성
                 * → SSO_GRP_POST_CRYPTO 그룹으로 도착
                 */
                submit_to_cpt(pkt, SSO_GRP_POST_CRYPTO);
                ev.op = RTE_EVENT_OP_RELEASE;
            } else {
                ev.queue_id = SSO_GRP_IPS;
                ev.op = RTE_EVENT_OP_FORWARD;
                /* SWTAG: Atomic → Ordered 전환 */
                ev.sched_type = RTE_SCHED_TYPE_ORDERED;
            }
            break;

        case SSO_GRP_POST_CRYPTO:  /* CPT 완료 이벤트 */
            /*
             * CPU가 CPT를 폴링하지 않음!
             * HW가 암호화 완료 → SSO에 이벤트 자동 생성
             */
            ev.queue_id = SSO_GRP_IPS;
            ev.sched_type = RTE_SCHED_TYPE_ORDERED;
            ev.op = RTE_EVENT_OP_FORWARD;
            break;

        case SSO_GRP_IPS:  /* Ordered 모드 */
            ips_pattern_match(pkt);
            /* NIX TX로 직접 전송 — 순서 자동 보장 */
            ev.queue_id = SSO_GRP_TX;
            ev.op = RTE_EVENT_OP_FORWARD;
            break;
        }

        rte_event_enqueue_burst(evdev_id, port_id, &ev, 1);
    }
}

/* 2. HW 타이머를 이용한 세션 타임아웃 */
static void setup_session_timeout(uint32_t flow_tag,
                                   uint64_t timeout_ns)
{
    /*
     * OCTEON TIM(Timer Wheel)에 타이머 등록
     * 만료 시 SSO 이벤트로 자동 변환 → CPU 인터럽트 불필요
     */
    struct rte_event_timer tim = {
        .ev.queue_id = SSO_GRP_TIMEOUT,
        .ev.sched_type = RTE_SCHED_TYPE_ATOMIC,
        .ev.flow_id = flow_tag,
        .timeout_ticks = timeout_ns / tim_tick_ns,
        .state = RTE_EVENT_TIMER_ARMED,
    };
    rte_event_timer_arm_burst(timer_adapter_id, &tim, 1);
    /* timeout_ns 후 SSO_GRP_TIMEOUT에 이벤트 도착 */
}

DLB vs SSO 종합 비교

NGFW 파이프라인에서의 이벤트 스케줄러 활용

기존 NGFW 데이터 플레인은 run-to-completion(단일 코어가 패킷을 끝까지 처리) 또는 SW 파이프라인(SW 큐로 단계 간 전달) 모델을 사용합니다. HW 이벤트 스케줄러는 이를 HW 파이프라인으로 대체하여 락 경합·캐시 미스·부하 불균형을 제거합니다.

 NGFW 이벤트 드리븐 파이프라인 예시 (DLB/SSO 공통)

 ┌──────────┐     ┌─────────┐     ┌──────────┐     ┌─────────┐
 │  NIC RX  │────▶│  HW     │────▶│  Stage 1 │────▶│  HW     │
 │ (패킷    │     │  Event  │     │ conntrack│     │  Event  │
 │  수신)   │     │  Sched  │     │ + ACL    │     │  Sched  │
 └──────────┘     │ [Atomic]│     │ (lock-   │     │[Ordered]│
                  └─────────┘     │  free)   │     └────┬────┘
                                  └──────────┘          │
                  ┌─────────────────────────────────────┘
                  │
                  ▼
 ┌──────────┐     ┌─────────┐     ┌──────────┐     ┌─────────┐
 │ Stage 2  │────▶│  HW     │────▶│  Stage 3 │────▶│  NIC TX │
 │ IPSec    │     │  Event  │     │  IPS/DPI │     │ (패킷   │
 │ 암복호화 │     │  Sched  │     │ 시그니처 │     │  송신)  │
 │ (QAT/CPT)│     │[Parallel│     │  매칭    │     └─────────┘
 └──────────┘     │ or Auto]│     └──────────┘
   ↑ HW 완료 시   └─────────┘      순서 복원은
   SSO: 자동 이벤트                  HW reorder 버퍼가
   DLB: SW re-enqueue              자동 처리

Fortinet NP7 / SP5

Fortinet FortiGate는 자체 ASIC 칩을 사용하여 데이터 플레인을 가속합니다. Inline ASIC(NP7) + Lookaside 코프로세서(SP5/CP9) 하이브리드 모델로, 패킷 전달은 NP7이 데이터 경로에서 직접(inline) 처리하고, 암호화·패턴 매칭은 전용 칩에 위임(lookaside)합니다:

• NP7 (Network Processor) — [Inline] 200Gbps L4 처리, HW session offload, IPSec/VXLAN/GRE 인라인 처리. Session table에 ESTABLISHED 세션을 등록하면 이후 패킷이 NP7에서 직접 전달됩니다.
• SP5 (Security Processor) — [Lookaside] SSL/TLS 가속, IPS 시그니처 매칭 보조. CPU에서 DPI를 수행하되 SP5가 암호화/복호화를 전담합니다.
• CP9 (Content Processor) — [Lookaside] AV/IPS/DLP 패턴 매칭 가속. CPU가 패턴 데이터를 CP9에 위임하여 병렬 매칭합니다.

NP7 세션 오프로드 프로세스(Process)

FortiGate에서 세션이 NP7으로 오프로드되는 과정:

1. 첫 패킷: CPU(IPS Engine)가 수신 → conntrack + UTM(IPS/AV/App Control) 전체 검사
2. 세션 수립: 검사 통과 시 CPU가 ISF(Iterate Session Filter)에 오프로드 결정 쿼리
3. NP7 등록: session_offload_add() → NP7 Session Table에 5-tuple + NAT 정보 + QoS 태그 기록
4. 후속 패킷: NP7 ASIC이 Session Table lookup → NAT rewrite → QoS → forwarding (CPU bypass)
5. 세션 종료: TCP FIN/RST → NP7이 CPU에 알림 → Session Table 삭제 → 통계 동기화

# FortiGate 진단 명령
diagnose npu np7 session-stats         # NP7 오프로드 세션 통계
diagnose npu np7 sse-stats all         # Session Search Engine 통계
diagnose npu np7 port-list             # NP7 포트 매핑 확인
diagnose sys session filter dport 443  # 특정 포트 세션 확인
get system performance firewall statistics # 전체 성능 통계

# NP7 오프로드 비율 확인
diagnose npu np7 session-stats
# 출력 예:
# NP7 offload sessions: 1,234,567
# CPU sessions: 12,345
# Offload ratio: 99.0%

# 특정 세션의 오프로드 상태 확인
diagnose sys session filter src 10.0.0.1
diagnose sys session list
# 출력에서 npu_state=offloaded 확인

SP5 (Security Processor) 암·복호화 아키텍처

SP5는 FortiGate의 SSL/TLS 전용 하드웨어 가속 프로세서입니다. CPU에서 수행하면 병목이 되는 TLS 핸드셰이크(비대칭키 연산)와 레코드 암·복호화(대칭키 연산)를 전담합니다.

SP5의 SSL Deep Inspection 파이프라인

FortiGate가 SSL Deep Inspection(SSL 딥 인스펙션)을 수행할 때의 내부 패킷 흐름입니다:

1. 클라이언트 → FortiGate TLS 핸드셰이크: SP5가 ECDHE/RSA 키 교환 수행. FortiGate의 CA 인증서로 서버 인증서를 동적 생성하여 클라이언트에 제공
2. FortiGate → 서버 TLS 핸드셰이크: SP5가 실제 서버와 별도의 TLS 세션 수립. 서버의 진짜 인증서를 검증
3. 데이터 복호화: SP5가 클라이언트 TLS 세션의 레코드를 하드웨어에서 복호화 → 평문을 CPU(IPS 엔진)에 전달
4. DPI/IPS 검사: CPU + CP9가 평문에 대해 App Control, IPS 시그니처 매칭, AV 스캔, DLP 수행
5. 재암호화: SP5가 서버 TLS 세션의 레코드로 재암호화 → NP7이 전달

# FortiGate SSL Inspection 진단 명령
diagnose sys session filter proto 6 dport 443
diagnose sys session list
# 출력에서 확인할 항목:
# npu_state=0 (SSL Inspection 세션은 offload 안 됨)
# ssl_action=deep-inspection
# ssl_cipher=ECDHE-RSA-AES256-GCM-SHA384

# SP5 처리 통계
diagnose hardware deviceinfo nic sp5
# SP5 crypto throughput:
#   Encrypt: 18.5 Gbps
#   Decrypt: 19.2 Gbps
#   Handshake: 95,000 TPS

# SSL Inspection 통계
get system performance firewall statistics
# ssl_proxy_sessions: 45,678
# ssl_proxy_bandwidth: 12.3 Gbps

# SSL Inspection 정책 설정
config firewall ssl-ssh-profile
  edit "deep-inspect"
    set ssl-anomaly-log enable
    config https
      set ports 443
      set status deep-inspection
      set cert-validation-timeout 30
    end
  next
end

# NP7 + SP5 협업 확인
diagnose npu np7 session-stats
# ssl_sessions_to_sp5: 45,678 (SP5로 전달된 SSL 세션)
# non_ssl_offloaded: 1,189,000 (NP7 오프로드된 비-SSL 세션)

NP7의 IPSec 암호화 처리 상세

NP7은 IPSec VPN 트래픽에 대해 ESP 패킷의 전체 처리(캡슐화 + 암호화 + 포워딩)를 하드웨어에서 수행합니다:

Palo Alto Networks FPGA

Palo Alto PA 시리즈는 FPGA 기반 SP3 (Security Processing) 아키텍처를 사용합니다. Inline FPGA + CPU 통합 모델로, 세션 오프로드는 FPGA가 inline 처리하고, DPI와 SSL은 범용 CPU에서 single-pass로 처리합니다. 전용 크립토 ASIC이 없어 SSL/IPSec은 CPU(AES-NI)에 의존하는 lookaside 구조입니다:

• Single-Pass Parallel Processing — [Inline CPU] 패킷이 한 번의 통과로 FW, App-ID, IPS, URL 필터링을 병렬 처리
• NPC (Network Processing Card) — 고성능 모델에 추가 가능한 데이터 플레인 카드
• FE (Forwarding Engine) FPGA — [Inline] 세션 테이블 lookup, NAT rewrite를 FPGA에서 처리
• CPU 코어에서 App-ID/DPI를 처리하되, FPGA가 세션 설정과 패킷 전달을 가속. SSL/IPSec 암·복호화는 CPU AES-NI [Lookaside]

Single-Pass 아키텍처 상세

Palo Alto의 핵심 차별점은 Single-Pass Parallel Processing (SP3) 아키텍처입니다:

FE FPGA의 역할: FPGA는 패킷 분류(5-tuple lookup), 세션 테이블 검색, 디캡슐레이션, NAT rewrite를 수행합니다. CPU는 App-ID 엔진만 실행하므로, FPGA가 처리할 수 있는 세션(이미 분류된 ESTABLISHED)은 CPU를 완전히 bypass합니다.

Palo Alto SSL 복호화 아키텍처

Palo Alto는 전용 크립토 ASIC 없이 범용 CPU 코어에서 SSL 복호화를 수행합니다. SP3 아키텍처의 핵심은 SSL 복호화를 Single-Pass 파이프라인의 일부로 통합하여, 별도의 프록시 단계 없이 인라인(Inline)에서 처리하는 것입니다.

Palo Alto의 접근법은 Fortinet(SP5 전용 칩)과 대조적입니다. 장점: 범용 CPU로 유연한 TLS 버전/cipher suite 지원 (TLS 1.3 초기 지원이 빨랐음). 단점: 전용 칩 대비 SSL 처리량이 낮고, SSL 활성화 시 CPU 부하가 크게 증가합니다.

# Palo Alto SSL 복호화 진단 명령
show counter global filter delta yes | match ssl
# ssl_proxy_session_new: 연결/초 (CPS)
# ssl_proxy_session_active: 현재 활성 SSL 세션
# ssl_decrypt_success: 복호화 성공 패킷
# ssl_decrypt_fail: 복호화 실패 (cipher 미지원 등)
# ssl_cert_verify_fail: 인증서 검증 실패

show session all filter ssl-decrypt yes
# SSL 복호화 중인 세션 목록

show system resources
# CPU 사용률 확인 → SSL 활성 시 증가폭

# SSL 복호화 정책 설정 (PAN-OS)
set rulebase decryption rules "decrypt-outbound" {
    from any; to any;
    source any; destination any;
    service any; action decrypt;
    type { ssl-forward-proxy { }; };
    profile "default";
}

# SSL 복호화 프로파일
set profiles decryption "strict" {
    ssl-forward-proxy {
        block-expired-certificate yes;
        block-untrusted-issuer yes;
        block-unsupported-version yes;
        block-unsupported-cipher yes;
        min-version tls1-2;
    };
}

# Palo Alto CLI 진단 명령
show running resource-monitor           # CPU/메모리/세션 사용률
show session all filter state active    # 활성 세션 목록
show session info                       # 세션 통계 (CPS, CC)
show counter global filter delta yes \
  packet-filter yes                     # 실시간 카운터
debug dataplane packet-diag set filter \
  match src 10.0.0.1                    # 특정 IP 패킷 추적

Check Point SecureXL / Maestro

Check Point는 순수 소프트웨어 기반(Inline 커널 가속) 아키텍처를 사용합니다. 전용 ASIC/FPGA 없이 범용 x86 CPU만으로 모든 처리를 수행하며, 커널 레벨 inline 가속(SecureXL)으로 성능을 확보합니다. SSL/IPSec 암·복호화도 CPU에서 수행(lookaside 코프로세서 없음)하므로, HTTPS Inspection 성능이 상대적으로 제한됩니다:

• SecureXL — [Inline 커널] 커널 레벨 가속. Accept Template(ESTABLISHED 세션 direct forward)과 Drop Template(미리 차단 목록)으로 CPU 부하를 줄입니다.
• CoreXL — [Inline CPU] 멀티코어 병렬 처리. SND(Secure Network Distributor)가 RSS처럼 코어 간 패킷을 분배합니다.
• Maestro HyperScale — 여러 Security Gateway를 하나의 논리 장비로 클러스터링하여 수평 확장
• SSL/IPSec — [CPU only, Lookaside HW 없음] 범용 CPU AES-NI로 처리. 전용 크립토 칩 부재로 HTTPS Inspection 시 성능 감소 큼

SecureXL 처리 경로 상세

SecureXL은 3가지 처리 경로(Accelerated Path, Medium Path, Firewall Path)로 패킷을 분류합니다:

Accept Template은 Linux conntrack의 ESTABLISHED + flowtable 개념과 유사합니다. conntrack이 세션 상태를 추적하고, Accept Template이 검사가 완료된 세션의 5-tuple을 커널 가속 테이블에 등록합니다. Drop Template은 이미 DROP 판정이 난 소스 IP/포트를 캐시하여, 동일한 악성 트래픽이 재전송(Retransmission)될 때 CPU까지 가지 않고 즉시 DROP합니다.

CoreXL / SND 아키텍처

Check Point의 멀티코어 아키텍처는 Linux의 RSS/RPS와 유사하지만 보안에 최적화되어 있습니다:

• SND (Secure Network Distributor) — 전용 코어가 NIC에서 패킷을 수신하여 CoreXL 인스턴스에 분배. CPU affinity 기반으로 세션을 고정 코어에 할당
• CoreXL FW Instance — 각 코어가 독립적인 FW 인스턴스를 실행. 세션 테이블은 공유하되, 처리는 병렬
• Multi-Queue — SND가 NIC의 RSS 큐를 활용하여 하드웨어 수준 분산

# Check Point 진단 명령 (Gaia OS)
fwaccel stat                            # SecureXL 가속 통계
fwaccel stats -s                        # 경로별 패킷/바이트 통계
fwaccel conns                           # Accept Template 연결 수
fw ctl multik stat                      # CoreXL 인스턴스별 통계
cpview                                  # 실시간 성능 모니터 (TUI)

# SecureXL 비활성화/활성화 (성능 비교 테스트)
fwaccel off     # 가속 비활성화 → 전체 Firewall Path
fwaccel on      # 가속 재활성화

# 특정 세션의 처리 경로 확인
fw ctl zdebug + drop    # 디버그 로그

Check Point HTTPS Inspection 아키텍처

Check Point는 Fortinet(SP5 전용 칩)이나 전용 크립토 ASIC 없이 순수 소프트웨어 기반의 HTTPS Inspection을 수행합니다. CoreXL의 멀티코어 병렬 처리와 SecureXL의 가속 경로를 조합하여 성능을 최적화합니다.

SecureXL과 HTTPS Inspection의 관계: HTTPS Inspection이 활성화되면 해당 세션은 Firewall Path(가장 느린 경로)에서 처리됩니다. Accelerated Path로 승격될 수 없으므로, HTTPS Inspection 비율이 높을수록 SecureXL 가속 효과가 감소합니다.

# Check Point HTTPS Inspection 진단
fwaccel stat
# Accelerated Conns: 1,200,000
# HTTPS Inspect Conns: 45,000 (Firewall Path)
# → HTTPS Inspection 세션은 Accelerated Path 불가

# HTTPS Inspection 통계
cpstat -f https_inspection fw
# Total inspected connections: 45,000
# Bypassed connections: 5,000 (bypass 규칙 적용)
# Certificate cache hit ratio: 85%

# CoreXL 인스턴스별 SSL 부하 분포
fw ctl multik stat
# 각 CoreXL 인스턴스의 CPU 사용률 확인
# HTTPS Inspection 활성 시 불균형 주의

# HTTPS Inspection 바이패스 규칙 (성능 최적화)
# SmartConsole → Security Policies → HTTPS Inspection
# 금융/의료 사이트, Windows Update 등 → Bypass 권장

Juniper Express Path

Juniper SRX 시리즈의 Express Path는 세션의 첫 패킷만 flow daemon이 처리하고, 이후 패킷은 NPU(Network Processing Unit)에서 직접 전달합니다. Inline NP + Lookaside SPC3 하이브리드 모델로, 패킷 전달은 NP가 데이터 경로에서 inline 처리하고, IPSec/SSL 암호화는 별도 SPC3 카드에 위임(lookaside)합니다:

• Express Path — [Inline] 확립된 세션의 패킷을 flowd를 bypass하여 NP에서 forwarding
• Services Offload Engine (SPC3) — [Lookaside] IPSec 크립토, SSL Proxy를 전용 카드에서 처리. CPU/NP에서 SPC3로 패킷을 전달하고 결과를 돌려받는 구조

Express Path 동작 원리

Juniper SRX의 패킷 처리 아키텍처:

1. NP (Network Processor): 모든 패킷의 1차 수신. 세션 테이블에서 lookup
2. Express Path 히트: 기존 세션 매칭 → NP에서 직접 forwarding + NAT rewrite (flowd bypass)
3. Express Path 미스: 새 세션 → flowd(flow daemon)로 전달 → 정책 평가 + IPS/AppID
4. 세션 설치: flowd가 정책 통과 시 세션을 NP Express Path 테이블에 등록

# Juniper SRX 진단 명령
show security flow statistics           # 플로우 통계 (Express Path 비율)
show security monitoring fpc 0          # FPC별 세션/처리량
show security flow session              # 세션 테이블
show security flow session summary      # 세션 요약 (활성/최대)

# Express Path 상태 확인
show pfe statistics traffic
# express-path-packets, slow-path-packets 비교

# Services Offload Engine 상태
show chassis fpc pic-status

SPC3 (Services Processing Card) 암호화 가속

Juniper SRX 5000 시리즈는 SPC3 카드를 통해 IPSec과 SSL 처리를 전용 하드웨어에서 가속합니다. SPC3는 NP(Network Processor)와 별도의 크립토 엔진을 내장하고 있어, 암·복호화 연산을 NP에서 분리하여 처리합니다.