상용 NGFW HW 아키텍처

Fortinet NP7/CP9/SoC5, Palo Alto SP3 FPGA, Check Point SecureXL/Maestro, Juniper Express Path 상용 NGFW 하드웨어 아키텍처 비교, SSL Inspection 오프로드 분류, 암호화 오프로드 아키텍처 3분류, 하드웨어 이벤트 스케줄러(DLB/SSO), Linux 커널 기반 NGFW, 벤더별 TLS 핸드셰이크·암호화·성능 비교, 배포 아키텍처 패턴, HA 구성, TLS 1.3/ECH 대응, PQC 영향, RFC 9411 성능 측정 방법론

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

대부분의 상용 NGFW는 두 모델을 혼합(Hybrid)하여 사용합니다. 다만 실무에서는 L4 세션 전달용 fast path와 SSL Inspection용 복호화 경로를 분리해서 봐야 합니다. 같은 장비라도 세션 포워딩은 inline인데, SSL/TLS 검사는 CPU중심 lookaside 또는 SoC중심 lookaside일 수 있습니다. 아래 표는 공개 자료 기준으로 이를 정리한 것입니다:

벤더별 SSL Inspection 오프로드 분류

SSL/TLS Inspection은 단순히 "암호화 가속" 하나로 끝나지 않습니다. 실제로는 ① TLS 핸드셰이크와 키 교환, ② 레코드 계층 AES-GCM/ChaCha20 암·복호화, ③ 평문 DPI와 정책 엔진, ④ 인증서/개인키 보관이 서로 다른 자원에 배치됩니다. 벤더별 차이는 바로 이 네 단계가 어디서 실행되는지에 있습니다.

암호화 오프로드 아키텍처 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 / CP9 / SoC5 계열

Fortinet FortiGate는 제품군에 따라 구현이 다르지만, 공개 자료 기준으로 보면 세션 전달용 Network Processor와 검사용 보안/콘텐츠 프로세서를 결합한 하이브리드 구조입니다. 고성능 chassis/데이터센터 계열은 NP7 계열이 inline fast path를 맡고, SSL Inspection과 콘텐츠 검사는 별도 inspection 경로가 담당합니다. 브랜치 SoC 장비는 SoC5(문서상 SP5/NP7Lite 언급 포함)처럼 동일 SoC 내부에 해당 기능이 더 밀집되어 있어 SoC중심 lookaside에 가까운 하이브리드로 보는 편이 정확합니다:

• NP7 / NP6 계열 (Network Processor) — [Inline] L2~L4 세션 오프로드, NAT, IPSec/VXLAN/GRE fast path. Session table에 ESTABLISHED 세션을 등록하면 이후 패킷이 NP에서 직접 전달됩니다.
• CP9 / CP10 및 보안 프로세서 경로 — [Lookaside 또는 SoC 내부 inspection path] 프록시 기반 SSL/TLS 검사, 콘텐츠 검사, 파일/패턴 매칭을 보조합니다.
• SoC5 / NP7Lite 계열 — [SoC-Centric Hybrid] 네트워크 처리와 inspection 가속기가 같은 패키지 안에 결합되어 branch 모델의 전력과 지연을 줄입니다.

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 확인

Fortinet 보안 프로세서/SoC inspection 경로

Fortinet 공개 자료는 제품군에 따라 CP9/CP10, SoC5, 보안 프로세서 등 서로 다른 명칭을 사용합니다. 공통점은 세션 전달용 NP fast path와 별도의 inspection 암호화 경로가 존재하는 점입니다. CPU가 TLS 정책과 평문 검사를 총괄하되, 핸드셰이크와 레코드 암·복호화의 상당 부분을 이 inspection 경로가 보조합니다.

Fortinet SSL Deep Inspection 파이프라인

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

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

# 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 SP3

Palo Alto Networks의 공개 자료는 SP3(Single-Pass Parallel Processing)의 핵심을 분리된 control plane/data plane, 병렬 처리 하드웨어, single-pass 소프트웨어로 설명합니다. 따라서 세션 fast path는 장비 내부 dataplane hardware가 inline으로 처리하지만, SSL/TLS 복호화와 평문 검사는 Fortinet이나 Juniper처럼 분리된 전용 SSL ASIC보다 dataplane CPU 자원에 밀착된 CPU중심 lookaside로 해석하는 편이 정확합니다. 다시 말해, 세션 분류는 inline이고 decryption은 SP3 파이프라인 안에서 CPU가 소화합니다:

• 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에서 분리하여 처리합니다.

# Juniper SRX SPC3 암호화 관련 진단
show security ipsec statistics
# ESP 암·복호화 패킷/바이트 통계

show security ipsec sa
# SA 목록 + 하드웨어 가속 여부

show services ssl proxy statistics
# SSL Proxy 세션 수, CPS, 처리량

show chassis fpc 0 pic 0
# SPC3 카드 상태 + 크립토 엔진 사용률

# SPC3 IPSec 오프로드 설정
set security ipsec vpn site-a {
    ike {
        gateway gw-site-a;
        ipsec-policy ipsec-pol;
    }
    establish-tunnels immediately;
}
# SPC3가 자동으로 IPSec 처리를 하드웨어에서 수행

SPC3 SSL Forward Proxy 핸드셰이크 처리

Juniper SRX의 SSL Forward Proxy는 SPC3 카드에서 TLS 핸드셰이크와 레코드 암·복호화를 전담합니다. flowd(Flow Daemon)는 평문 DPI만 수행하므로, 암호화 연산 부하가 CPU에 집중되지 않습니다.

Linux 커널 기반 NGFW

Linux 커널과 오픈소스 도구를 조합하여 NGFW를 구축하는 접근법입니다. Inline SmartNIC + Lookaside SW 하이브리드 모델로, EST 세션은 SmartNIC eSwitch가 inline 처리(라인레이트)하고, DPI는 NFQUEUE를 통해 유저스페이스 Suricata에 위임(lookaside)합니다. 암호화는 NIC inline crypto 또는 QAT lookaside를 선택할 수 있습니다:

• nftables + NFQUEUE + Suricata — [Lookaside] 커널 네이티브 방화벽 + 유저스페이스 DPI
• nf_flowtable + SmartNIC — [Inline] eSwitch FDB HW offload로 EST 세션 라인레이트 가속
• IPSec (xfrm) — [Inline] NIC inline crypto 또는 [Lookaside] QAT 가속
• kTLS — [Inline] NIC TLS offload 또는 [Lookaside] QAT 가속
• VPP 기반 대안 — FD.io VPP의 유저스페이스 데이터 플레인으로 Netfilter 대신 패킷 처리

Linux NGFW 스택 구성

Linux 커널 기반 NGFW를 상용 수준으로 구축하기 위한 전체 스택:

VPP 기반 NGFW 데이터 플레인

FD.io VPP를 사용하면 커널 Netfilter 대신 유저스페이스에서 패킷 처리하여 더 높은 성능을 달성합니다:

• 장점: 벡터 패킷 처리(batch), DPDK 기반 NIC 접근, 커널 overhead 제거 → 단일 코어 40Gbps+
• 단점: 커널 네트워크 스택(conntrack, nftables, flowtable)을 사용할 수 없음. VPP 자체 ACL/NAT 플러그인 사용
• 하이브리드 접근: VPP가 Fast Path를 처리하고, 새 세션만 TAP 인터페이스를 통해 커널/Suricata로 전달

# VPP 기반 NGFW 설정 예시
# /etc/vpp/startup.conf
dpdk {
  dev 0000:03:00.0 { name eth0 }
  dev 0000:03:00.1 { name eth1 }
}

# VPP CLI에서 ACL + session 설정
vppctl acl-plugin acl add permit+reflect \
  src 10.0.0.0/8 dst 0.0.0.0/0 proto tcp
vppctl set acl-plugin interface eth0 input acl 0

# 새 세션만 TAP으로 전달 (DPI)
vppctl create tap id 0
vppctl set interface state tap0 up

Linux NGFW SSL/TLS 검사 아키텍처

Linux 기반 NGFW에서 SSL/TLS 검사는 여러 오픈소스 컴포넌트를 조합하여 구현합니다. 상용 NGFW와 달리 단일 통합 솔루션이 아닌 계층별 독립 도구의 조합이며, 각 계층에서 inline/lookaside HW 가속을 선택적으로 적용할 수 있습니다.

SSL 검사 아키텍처 선택지

Linux NGFW에서 SSL/TLS 트래픽을 검사하는 대표적인 3가지 아키텍처입니다:

벤더별 SSL/TLS 핸드셰이크 처리 비교

모든 NGFW의 SSL/TLS Inspection은 MITM(Man-in-the-Middle) TLS Proxy 방식입니다. 클라이언트와 서버 사이에 두 개의 독립된 TLS 세션을 수립하고, NGFW가 중간에서 복호화 → DPI → 재암호화를 수행합니다. 벤더 간 차이는 각 TLS 핸드셰이크 단계의 처리 위치(CPU vs 전용 HW)와 처리 방식(inline vs lookaside)에 있습니다.

TLS 핸드셰이크 단계별 벤더 비교

SSL/TLS 처리 성능 비교

상용 NGFW 암호화 처리 비교

암·복호화 트래픽 관점에서 각 벤더의 아키텍처를 비교합니다. SSL/TLS Inspection과 IPSec VPN 처리는 NGFW 성능에서 가장 큰 차이를 만드는 영역입니다.

NGFW 배포 아키텍처 패턴

NGFW를 네트워크에 배치하는 방식에 따라 가시성, 성능 영향, 장애 복원력이 달라집니다. 배포 모드는 크게 4가지로 분류되며, 각 모드에서 HW 오프로드의 적용 범위가 다릅니다.

인라인 배포의 장애 대응: HW 바이패스

인라인 브릿지/라우팅 배포에서 NGFW 장애 시 네트워크 단절을 방지하기 위해 HW 바이패스(Hardware Bypass) 모듈을 사용합니다. 바이패스는 전기·광학 수준에서 패킷을 NGFW를 우회하여 직접 전달합니다.

# SmartNIC 바이패스 모드 설정 (Silicom 예시)
# Watchdog 타이머 설정 — 5초 무응답 시 자동 바이패스
bpctl_util eth0 set_bypass_wd 5000   # 5000ms = 5초

# 바이패스 상태 확인
bpctl_util eth0 get_bypass
# bypass: off (normal mode)

# 수동 바이패스 전환 (유지보수 시)
bpctl_util eth0 set_bypass on

# Intel E810 NIC 바이패스 (ice 드라이버)
ethtool --set-priv-flags eth0 bypass on

고가용성(HA) 아키텍처

NGFW의 HA 구성은 세션 동기화가 핵심입니다. 장애 발생 시 기존 세션이 끊기지 않으려면 Active 장비의 conntrack 테이블을 Standby 장비에 실시간 복제해야 합니다.

# Linux NGFW HA 구성 — conntrackd + Keepalived

# 1. conntrackd — 세션 테이블 실시간 동기화
# /etc/conntrackd/conntrackd.conf
Sync {
    Mode FTFW {                    # Fault Tolerant FW 모드
        ResendQueueSize 131072
        ACKWindowSize 300
    }
    Multicast {
        IPv4_address 225.0.0.50
        Group 3780
        IPv4_interface 192.168.100.1
        Interface eth2              # 전용 동기화 인터페이스
    }
}
General {
    HashSize 32768
    HashLimit 131072
    Syslog on
    LockFile /var/lock/conntrack.lock
    UNIX { Path /var/run/conntrackd.ctl }
    Filter From Userspace {
        Protocol Accept {
            TCP SCTP DCCP
        }
        Address Ignore {
            IPv4_address 127.0.0.1
            IPv4_address 192.168.100.0/24  # 동기화 서브넷 제외
        }
    }
}

# 2. Keepalived — VIP failover
# /etc/keepalived/keepalived.conf
vrrp_instance NGFW_HA {
    state MASTER
    interface eth0
    virtual_router_id 51
    priority 100
    advert_int 1
    authentication {
        auth_type PASS
        auth_pass ngfw_ha_secret
    }
    virtual_ipaddress {
        10.0.0.1/24       # 게이트웨이 VIP
    }
    notify_master "/etc/conntrackd/primary-backup.sh primary"
    notify_backup "/etc/conntrackd/primary-backup.sh backup"
    notify_fault  "/etc/conntrackd/primary-backup.sh fault"
}

# 3. failover 스크립트 — primary-backup.sh
# primary 승격 시 conntrackd에서 세션 테이블 bulk 로드
# conntrackd -C /etc/conntrackd/conntrackd.conf -c
# conntrackd -C /etc/conntrackd/conntrackd.conf -B

TLS 1.3/ECH와 SSL Inspection의 미래

TLS 1.3과 ECH(Encrypted Client Hello)의 확산은 NGFW SSL Inspection에 근본적인 도전을 제기합니다. 기존 SSL Inspection의 핵심 가정 — ClientHello에서 SNI를 읽을 수 있고, MITM 프록시를 통해 복호화할 수 있습니다 — 이 흔들리고 있습니다.

TLS 1.3이 NGFW에 미치는 영향

ECH(Encrypted Client Hello)의 도전

ECH는 TLS ClientHello의 SNI 필드를 암호화하여 중간자(NGFW 포함)가 접속 대상 서버를 식별하지 못하게 합니다. 이는 SNI 기반 SSL Inspection 정책의 핵심 전제를 무력화합니다.

NGFW 벤더별 ECH 대응 전략:

포스트 양자(PQC) 암호화와 NGFW

NIST가 표준화한 포스트 양자 암호화 알고리즘(ML-KEM, ML-DSA)이 TLS에 도입되면, NGFW의 SSL Inspection 성능에 직접적인 영향을 미칩니다.

상용 vs Linux NGFW 선택 기준

상용 NGFW와 Linux 기반 NGFW는 하드웨어 아키텍처뿐 아니라 운영 모델, 비용 구조, 조직 역량 요구사항이 근본적으로 다릅니다. 아래 표는 실무에서 선택 시 고려해야 할 핵심 차원을 정리합니다.

시나리오별 선택 가이드

성능 비교 벤치마크 (참고 수치)

다음은 공개된 데이터시트와 독립 벤치마크(NSS Labs, RFC 9411 기반)에서 추출한 참고 수치입니다. 실제 환경에서는 정책 복잡도, 트래픽 믹스, DPI 시그니처 수에 따라 크게 달라집니다:

Linux NGFW의 NGFW 처리량은 Suricata DPI에 의해 제한되지만, FW 처리량(L4 stateful)에서는 SmartNIC HW offload로 상용 제품에 필적하는 성능을 달성합니다. 핵심은 오프로드 비율을 높여 DPI 부하를 최소화하는 것입니다.

NGFW 성능 측정 방법론 (RFC 9411)

RFC 9411 (Benchmarking Methodology for Network Security Device Performance)은 NGFW 성능을 표준화된 방식으로 측정하기 위한 IETF 표준입니다. 벤더 데이터시트의 수치는 대부분 최적 조건에서 측정되므로, 실제 환경 성능을 예측하려면 RFC 9411 기반 독립 벤치마크가 필수입니다.

핵심 성능 메트릭

트래픽 프로파일과 성능 변동

데이터시트 수치와 실제 성능의 격차는 트래픽 프로파일에 의해 결정됩니다. RFC 9411은 다양한 실 환경 트래픽 패턴을 반영한 테스트를 권고합니다.

참고자료

벤더 기술 문서

• NVIDIA MLNX_OFED: Connection Tracking Offload — ConnectX-6/7 CT offload 설정 가이드
• NVIDIA BlueField: TC Flower Offload — BlueField DPU TC flower 규칙 HW offload
• NVIDIA ConnectX-7 Product Brief — ConnectX-7 NIC 사양 및 오프로드 기능
• NVIDIA Crypto Offload — ConnectX-6 Dx/7 IPSec, TLS 하드웨어 암호화 오프로드
• Intel ICE Driver (E810) — E810 eSwitch switchdev 모드 지원 드라이버
• Broadcom SmartNIC — Stingray PS1100R, 하드웨어 방화벽 오프로드

표준/벤치마크

• RFC 9411: Benchmarking Methodology for Network Security Device Performance — NGFW 벤치마크 표준 방법론
• RFC 3511: Benchmarking Methodology for Firewall Performance — 전통 방화벽 벤치마크 (RFC 9411의 기반)
• FortiGate 7000 Series Data Sheet — Fortinet 7081F 사양
• PA-5400 Series Data Sheet — Palo Alto PA-5440 사양
• Check Point Quantum Gateway 모델 비교 — Check Point 28000 시리즈 사양