VPP on DPU

VPP를 서버 CPU 대신 DPU(Data Processing Unit, BlueField 같은 SmartNIC형 연산 장치)에 올릴 때의 흐름·분할·SSL Inspection 오프로드를 0~15 소절로 심화 정리한 문서입니다. 본 문서는 운영 · 플랫폼 · 확장에서 DPU 섹션만을 분리한 심화 분리본이며, vpp-operations.html의 운영 본문은 그대로 두고 DPU 고유 설계만 이곳에서 깊이 다룹니다.

이 페이지(Page)에서 다루는 주요 흐름은 다음과 같습니다. 0번에서 SSL Inspection의 개념·필요성·최소 구현을 먼저 정리한 뒤, 1번에서 DPU와 SmartNIC의 차이를 설명합니다. 2번은 DPU에 VPP를 올리는 세 가지 배포 패턴을, 3번은 DPU VPP 빌드와 부팅 차이를 다룹니다. 4번은 cryptodev/HSM 같은 가속기 연동을 VPP 측 추상화 관점에서 정리하고, 5번은 SSL Inspection on DPU의 핵심 설계를 종합합니다. 6번은 VPP 설정으로 보는 구성 예시이며, 6.5번은 DPU↔Host 왕복 배치의 VCL+OpenSSL 구현을 5개 하위 소절(흐름·VCL 골격·Host forwarder·바이트 워크·함정)로 풀어냅니다. 7번은 성능과 운영 포인트, 8번은 호스트 경로와 DPU 경로의 패킷(Packet) 워크 비교, 9번은 TLS 1.3 핸드셰이크 단계별 트레이스, 10번은 동적 leaf 인증서와 cert cache, 11번은 세션 계층 배선을 VPP 코드 관점에서 다룹니다. 12번은 그래프 노드 워크스루, 13번은 관측·디버깅(Debugging), 14번은 실습 랩 스켈레톤, 마지막 15번은 한 장 요약입니다.

DPU에서 VPP 구현 — 흐름·분할·SSL Inspection 오프로드

이 절은 "VPP를 서버 CPU 대신 DPU(Data Processing Unit)에 올린다"는 구체적 상황을 전제로, 무엇이 달라지고 무엇을 추가로 고려해야 하는지를 정리합니다. 특히 SSL Inspection처럼 TCP 재조립·TLS 레코드 암복호화(Decryption)·인증서 서명이 동시에 필요한 워크로드는 DPU 배포에서 가장 큰 설계 포인트가 되므로, 이 시나리오를 중심축으로 삼아 설명합니다. 일반 프록시·TLS 종단 내용은 TCP/TLS 프록시의 SSL Inspection을, 정책·거버넌스 관점은 보안과 터널링의 SSL Inspection 보안 통합을 함께 참고하시기 바랍니다.

1. DPU란 무엇인가 — SmartNIC와의 관계

DPU는 기존의 스마트 NIC(SmartNIC) 흐름이 자연스럽게 도달한 한 형태로, 세 개의 층이 한 카드 안에 통합된 장치입니다.

1. 고속 NIC ASIC — 100/200/400GbE 이더넷 MAC/PHY, 플로우 매칭 엔진(eSwitch, P4 파이프라인), 호스트/업링크 양방향 포트.
2. 범용 컴퓨팅 코어 — 대개 8~16개의 Arm Cortex-A 코어, 자체 DDR 메모리, 독립 운영체제(리눅스). 호스트와 PCIe를 통해 연결되지만 별도의 CPU complex로 동작합니다.
3. 도메인 특화 가속기 — AES-GCM/ChaCha20 같은 대칭 암호화(대개 IPsec·TLS record용), RegEx, 압축, SHA/공개키 가속, 연결 추적(Connection Tracking, conntrack), RDMA 오프로드 엔진.

대표 제품군은 NVIDIA BlueField-2/3, Intel IPU E2000/Mount Evans, AMD(구 Pensando) DSC, Marvell Octeon 등이며, 배포 모드(하드웨어가 어떤 "가면"을 쓰고 호스트에 노출되는가)에 따라 VPP를 올리는 방식이 달라집니다.

2. DPU에 VPP를 올리는 세 가지 패턴

DPU는 호스트에 어떻게 "보이느냐"에 따라 배포 모드가 달라지고, 그에 맞춰 VPP의 책임 범위도 바뀝니다. 여기서는 현장에서 가장 많이 만나는 세 가지 패턴을 정리합니다.

SSL Inspection처럼 "호스트를 믿지 않겠다"는 요구가 있는 경우 B 모드가 기본 선택지입니다. 클라이언트 프라이빗 키와 CA 키를 호스트 OS가 아니라 DPU의 TPM/HSM(Hardware Security Module)에 보관할 수 있고, 호스트가 탈취되어도 복호화된 평문은 DPU 메모리에서만 존재하다 사라지기 때문입니다. 반면 "복호화 후 DLP/IDS로 넘긴다"처럼 후속 처리까지 고려하면 C 모드로 호스트 VPP를 L7 분석 티어로 붙이는 쪽이 확장성이 좋습니다.

3. DPU VPP 빌드와 부팅 — 무엇이 달라지는가

DPU Arm에서 VPP를 돌릴 때 처음 만나는 벽은 빌드 타깃과 드라이버 스택입니다. 호스트 x86 경험을 그대로 가져올 수 없는 부분만 모아 정리했습니다.

# 1) 타깃: aarch64 — 호스트에서 크로스 빌드하거나, DPU에 직접 빌드
#    BlueField의 경우 NVIDIA DOCA BSP(Board Support Package)가 제공하는
#    aarch64 빌드 환경(Ubuntu 22.04 기반)에서 그대로 make build-release가 동작합니다.
dpu$ sudo apt install -y build-essential python3 libnuma-dev libmnl-dev \
                         libssl-dev libelf-dev libpcap-dev
dpu$ git clone https://github.com/FDio/vpp.git
dpu$ cd vpp && make install-dep && make build-release

# 2) 드라이버 스택: mlx5 계열은 커널 모듈(mlx5_core/ib_core)로 DPDK가 감쌉니다.
#    x86에서 익숙한 "vfio-pci로 bind 후 dpdk가 take over"가 아니라,
#    BlueField에서는 kernel이 먼저 mlx5_core로 잡고 DPDK는 bifurcated driver로 동거합니다.
dpu$ lsmod | grep mlx5
  mlx5_ib   ...
  mlx5_core ...
dpu$ ibv_devices        # RDMA 장치로도 보임 (rdma-core)
dpu$ dpdk-devbind.py -s # "kernel" 상태여도 DPDK가 사용 가능

# 3) startup.conf — Arm 8코어 BlueField-2 예시
dpu$ cat /etc/vpp/startup.conf
unix {
  nodaemon
  log /var/log/vpp/vpp.log
  cli-listen /run/vpp/cli.sock
}
cpu {
  main-core 1
  corelist-workers 2-5         # Arm 코어 4개만 워커로 — 2코어는 OS/관리용 여유
}
buffers {
  buffers-per-numa 32768       # DPU DDR은 작음(8~64GB) → 버퍼 수 보수적으로
  default data-size 2048
}
dpdk {
  dev 0000:03:00.0 { num-rx-queues 4 }      # 업링크(wire 방향)
  dev 0000:03:00.1 { num-rx-queues 4 }      # 호스트 방향(virtio 백엔드)
  # 가속기 활성화 — mlx5_crypto PMD를 cryptodev로 노출
  vdev crypto_mlx5
}
plugins {
  plugin dpdk_plugin.so { enable }
  plugin crypto_native_plugin.so { disable }   /* 가속기를 쓰므로 AESNI SW 경로 끔 */
  plugin crypto_openssl_plugin.so { enable }
  plugin tlsopenssl_plugin.so { enable }
}

4. DPU 가속기 연동 — VPP 측 추상화

VPP는 암호화 연산을 crypto engine 프레임워크(src/vnet/crypto)를 통해 추상화합니다. 알고리즘(AES-GCM, ChaCha20-Poly1305, HMAC-SHA256 등)별로 여러 엔진 구현이 등록되고, 운영자는 "어느 엔진을 어떤 알고리즘에 쓸지"를 런타임에 선택할 수 있습니다. DPU 가속기는 이 프레임워크 위에 DPDK cryptodev를 감싸는 엔진으로 올라옵니다.

/* src/plugins/dpdk/cryptodev/cryptodev_op_data_path.c — 핵심만 추림 */
static u32
cryptodev_frame_enqueue_gcm (vlib_main_t *vm,
                             vnet_crypto_async_frame_t *frame,
                             void *user_data)
{
    cryptodev_engine_thread_t *cet = &cryptodev_inst->per_thread_data[vm->thread_index];
    rte_crypto_op *cops[VNET_CRYPTO_FRAME_SIZE];

    for (u32 i = 0; i < frame->n_elts; i++)
    {
        /* 1) VPP의 crypto op를 DPDK rte_crypto_op로 변환 */
        cops[i] = rte_crypto_op_alloc(cet->op_pool, RTE_CRYPTO_OP_TYPE_SYMMETRIC);
        cops[i]->sym->m_src = vlib_buffer_to_mbuf(frame->elts[i].buffer_index);
        cops[i]->sym->aead.data.offset = frame->elts[i].crypto_start_offset;
        cops[i]->sym->aead.data.length = frame->elts[i].crypto_total_length;
        cops[i]->sym->aead.aad.data   = frame->elts[i].aad;
        cops[i]->sym->session         = cet->sessions[frame->elts[i].key_index];
    }

    /* 2) 배치 단위로 DPU 하드웨어 큐에 submit (doorbell 1회) */
    u32 n_enq = rte_cryptodev_enqueue_burst(
        cet->cryptodev_id, cet->cryptodev_q, cops, frame->n_elts);

    /* 3) 프레임을 in-flight 리스트에 매달아 두고 return — 진짜 완료는 dequeue에서 */
    cryptodev_mark_frame_inflight(cet, frame, n_enq);
    return n_enq;
}

5. SSL Inspection on DPU — 핵심 설계

SSL Inspection을 DPU에 올리는 이유는 세 가지입니다. ① 라인레이트(line-rate)에 가까운 TLS 종단이 필요하고, ② 호스트 OS와 분리된 키 격리(Key Isolation)가 중요하며, ③ 복호화된 평문이 호스트 메모리에 절대 나타나면 안 되는 요구사항이 존재하기 때문입니다. 구현 관점에서는 VPP host stack의 TCP 재조립, TLS 레코드 암복호화, 인증서 서명이 모두 DPU 안에서 끝나야 하며, 이 세 작업을 가속기와 Arm 코어가 어떻게 분담하는지가 설계의 핵심입니다.

핵심은 다음 네 가지입니다.

1. 두 개의 독립된 TLS 상태 머신 — 클라이언트 측 세션과 서버 측 세션은 VPP host stack 안에서 별도의 tls_ctx_t로 관리됩니다. ClientHello에서 SNI를 뽑아 업스트림 연결을 결정하고, 동시에 그 SNI에 맞는 임시 서버 인증서를 내부 CA로 즉석 서명하여 클라이언트에 제시합니다.
2. AEAD는 가속기로, 핸드셰이크는 Arm으로 — 대량 트래픽에 해당하는 AES-GCM/ChaCha20은 cryptodev(mlx5_crypto 등)에 배치 처리로 밀어 넣고, 상대적으로 저빈도인 핸드셰이크(ECDHE·인증서 검증)는 Arm 코어의 OpenSSL로 돌립니다. 이 분업이 "DPU 7배 효율"의 실체입니다.
3. 동적 서명은 HSM으로 우회 — 임시 서버 인증서 서명에 쓰이는 CA 개인키는 Arm 코어 메모리에 평문으로 올라오지 않아야 합니다. VPP는 OpenSSL의 PKCS#11 엔진을 통해 HSM/TPM에 signing 작업을 위임하고, 개인키는 HSM 밖으로 나가지 않습니다.
4. 평문 영역의 경계 관리 — 복호화된 HTTP가 노출되는 "평문 구간"은 DPU 메모리 안의 vlib 버퍼에만 존재합니다. DPI/정책 매칭이 끝나면 즉시 재암호화되어 업스트림으로 나가며, 필요하다면 별도 감사 전용 pipe(예: memif 채널)를 통해서만 호스트 측 분석 티어로 복사됩니다. 이 pipe는 mTLS로 인증되어야 하며, 설계상 단방향이어야 합니다.

6. 구성 예시 — VPP 설정으로 보는 SSL Inspection on DPU

# 1) TLS 엔진으로 openssl 선택, async crypto로 cryptodev 엔진 지정
dpu# set session enable
dpu# tls openssl set ciphers TLS_AES_128_GCM_SHA256:TLS_CHACHA20_POLY1305_SHA256
dpu# set crypto async handler aes-128-gcm cryptodev
dpu# set crypto async handler aes-256-gcm cryptodev
dpu# set crypto async handler chacha20-poly1305 cryptodev
dpu# set crypto async dispatch on

# 2) 내부 CA를 PKCS#11 HSM URI로 로드 (OpenSSL pkcs11 engine 사용)
#    - 개인키는 DPU 메모리로 절대 나오지 않음
dpu# tls openssl set-engine pkcs11
dpu# tls ca-cert pkcs11:token=DPU_CA;object=SSLI-CA-ECC
dpu# tls ca-key  pkcs11:token=DPU_CA;object=SSLI-CA-ECC-PRIV?pin-source=/dev/shm/pin

# 3) 이중 세션(투명 프록시) 세팅 — 클라이언트와 업스트림 양쪽에 listener 생성
dpu# tls-inspect proxy add listener 0.0.0.0:443 upstream-resolve dns \
                upstream-verify strict \
                dynamic-cert on \
                alpn http/1.1,h2

# 4) 정책 — 평문 버퍼를 DPI 엔진으로 연결
dpu# regex set backend rte_regexdev device mlx5_regex
dpu# ssli policy add match regex-set IDS-SIGNATURES action log
dpu# ssli policy add match host "*.bank.example" action bypass   # 우회

# 5) 감사 채널 — 호스트 분석 티어로 "평문 메타데이터"만 단방향 송신
dpu# create memif socket id 1 filename /run/vpp/ssli-audit.sock
dpu# create interface memif id 1 socket-id 1 master
dpu# ssli audit sink memif1 fields sni,host,url,verdict  # 페이로드 제외

# 6) 상태 확인
dpu# show ssli sessions
dpu# show crypto async status
dpu# show tls ctx detail

6.5 심화 구성 — DPU↔Host 왕복 배치의 VCL+OpenSSL 구현

실전 DPU 배포에서 자주 등장하는 한 가지 흐름이 "복호화는 DPU에서, L7 분석·포워딩은 호스트에서, 재암호화는 다시 DPU에서" 하는 왕복(bounce) 모델입니다. 사용자 요청 표기 그대로 정리하면 다음 한 줄이 됩니다.

Rx ─▶ (Client & Server SSL MITM) DPU ─▶ (Plain TCP) HostCPU (Forward) ─▶ DPU (Client & Server SSL MITM) ─▶ Tx

왕복이 일어나는 이유는 두 축이 서로 상충하기 때문입니다. ① 암호·키 격리는 DPU에 있어야 빠르고 안전하지만, ② 풍부한 L7 분석(DLP 엔진, 레거시 IDS 룰, DPI 플러그인, 로깅 파이프라인)은 이미 호스트 CPU에 쌓아 둔 생태계를 재활용(Recycling)하는 편이 현실적입니다. 평문을 호스트로 한 번 넘겨 검사·수정·포워딩 결정을 마친 뒤 다시 DPU로 돌려보내 재암호화하면, 두 축의 이점을 모두 살릴 수 있습니다. 이 소절은 그 흐름을 VCL(VPP Comms Library)과 OpenSSL만으로 구현하는 골격을 제시합니다. 본격 플러그인(vnet/tls)을 건드리지 않고도 프로토타입이 가능하기 때문에, 현장에서 POC용으로 가장 자주 쓰이는 조합입니다.

6.5.1 데이터 흐름과 주체 분담

흐름을 바이트 관점에서 풀어 쓰면 다음과 같습니다. 각 단계는 이어지는 코드에서 한 줄씩 대응됩니다.

1. Rx 진입 (DPU) — 업링크 NIC의 eSwitch 플로우가 TCP/443 트래픽을 DPU 상 VPP로 보내고, VCL listener가 accept합니다. VCL 세션 위에 OpenSSL SSL*(서버 역할) 객체가 붙습니다.
2. ClientHello 파싱 · 업스트림 연결 (DPU) — SNI를 보고 원서버로 두 번째 VCL 세션을 vppcom_session_connect()로 여는 동시에, OpenSSL(클라이언트 역할) 핸드셰이크를 시작합니다.
3. 원서버 leaf 확보 → SignLeaf (DPU) — 업스트림 핸드셰이크가 SSL_get_peer_certificate()까지 오면, HSM의 CA 키로 leaf를 서명해 클라이언트 방향 SSL_CTX에 주입합니다. cert cache 히트면 이 단계를 건너뜁니다.
4. Session A 완료 → 평문 루프 진입 (DPU) — 클라이언트 핸드셰이크가 Finished까지 도달하면 양 방향 SSL_read()/SSL_write() 루프가 열립니다. 이때 읽어낸 평문은 원서버로 바로 재암호화하지 않고 memif로 호스트에 먼저 넘깁니다.
5. Plain TCP forward (Host) — 호스트 VPP/애플리케이션이 memif로 수신한 바이트에 DLP/ICAP/IDS를 적용합니다. 통과 판정이면 역방향 memif로 돌려보내고, 차단이면 RST 메타를 DPU로 보냅니다.
6. 재암호화 → Tx (DPU) — 호스트에서 돌아온 바이트를 SSL_write()(클라이언트 역할)로 원서버 방향에 흘려 보내면 DPU의 AES-GCM 가속기가 레코드를 생성해 업링크로 송출합니다. 반대 방향(Origin→Client)은 대칭적으로 동작합니다.

6.5.2 DPU 측 골격 — VCL 세션 + OpenSSL BIO

VCL은 "POSIX socket과 비슷하지만 VPP의 세션 계층 위에서 동작하는" 사용자 라이브러리입니다. 그 자체에는 TLS 기능이 없으므로, OpenSSL을 얹으려면 VCL 전용 BIO를 만들어 SSL_set_bio()로 주입하는 것이 정석입니다. BIO의 read/write 콜백이 각각 vppcom_session_read()와 vppcom_session_write()를 호출하도록 구현하면, OpenSSL은 평범한 소켓에 붙은 것처럼 동작합니다.

/* dpu_ssli.c — DPU 측 VCL+OpenSSL MITM 골격
 * 빌드: gcc dpu_ssli.c -o dpu_ssli -lvppcom -lssl -lcrypto
 * 실행: LD_LIBRARY_PATH=... VCL_CONFIG=/etc/vpp/vcl.conf ./dpu_ssli
 * 교육용 골격 — 동시성(epoll), 오류 처리, 정책 훅은 단순화.
 */
#include <vppcom.h>
#include <openssl/ssl.h>
#include <openssl/bio.h>
#include <openssl/err.h>
#include <string.h>

/* 1) VCL 세션을 OpenSSL BIO로 감싼다 ------------------------------*/
static int vcl_bio_write(BIO *b, const char *buf, int len) {
    int sh = (int)(intptr_t)BIO_get_data(b);
    int r = vppcom_session_write(sh, (void*)buf, len);
    BIO_clear_retry_flags(b);
    if (r == VPPCOM_EAGAIN) { BIO_set_retry_write(b); return -1; }
    return r;
}
static int vcl_bio_read(BIO *b, char *buf, int len) {
    int sh = (int)(intptr_t)BIO_get_data(b);
    int r = vppcom_session_read(sh, buf, len);
    BIO_clear_retry_flags(b);
    if (r == VPPCOM_EAGAIN) { BIO_set_retry_read(b); return -1; }
    return r;
}
static long vcl_bio_ctrl(BIO *b, int cmd, long n, void *p) {
    if (cmd == BIO_CTRL_FLUSH) return 1;
    return 0;
}
static BIO_METHOD *vcl_bio_method(void) {
    static BIO_METHOD *m;
    if (!m) {
        m = BIO_meth_new(BIO_TYPE_SOURCE_SINK, "vcl");
        BIO_meth_set_write(m, vcl_bio_write);
        BIO_meth_set_read(m, vcl_bio_read);
        BIO_meth_set_ctrl(m, vcl_bio_ctrl);
    }
    return m;
}
static BIO *vcl_bio_new(int session_handle) {
    BIO *b = BIO_new(vcl_bio_method());
    BIO_set_data(b, (void*)(intptr_t)session_handle);
    BIO_set_init(b, 1);
    return b;
}

/* 2) SNI 콜백 — ClientHello에서 호스트 이름을 뽑고 leaf 캐시를 조회 -*/
typedef struct mitm_ctx { char sni[256]; int up_sh; SSL *up_ssl; } mitm_ctx_t;

static int sni_cb(SSL *s, int *al, void *arg) {
    mitm_ctx_t *c = SSL_get_ex_data(s, 0);
    const char *name = SSL_get_servername(s, TLSEXT_NAMETYPE_host_name);
    if (!name) return SSL_TLSEXT_ERR_NOACK;
    snprintf(c->sni, sizeof c->sni, "%s", name);

    /* 3) 업스트림 연결: VCL connect + OpenSSL client 핸드셰이크 */
    c->up_sh = vppcom_session_create(VPPCOM_PROTO_TCP, 0);
    vppcom_endpt_t ep = { .is_ip4 = 1, .port = htons(443) };
    resolve(name, ep.ip);                   // DNS는 호스트/외부 리졸버 위임
    vppcom_session_connect(c->up_sh, &ep);

    SSL_CTX *cli = SSL_CTX_new(TLS_client_method());
    SSL_CTX_set_verify(cli, SSL_VERIFY_PEER, NULL);
    SSL_CTX_set_default_verify_paths(cli);
    c->up_ssl = SSL_new(cli);
    SSL_set_tlsext_host_name(c->up_ssl, name);
    SSL_set_bio(c->up_ssl, vcl_bio_new(c->up_sh), vcl_bio_new(c->up_sh));
    if (SSL_connect(c->up_ssl) <= 0) { *al = SSL_AD_INTERNAL_ERROR; return SSL_TLSEXT_ERR_ALERT_FATAL; }

    /* 4) 원서버 leaf → SignLeaf → 클라이언트 방향 인증서 교체 */
    X509 *up_leaf = SSL_get_peer_certificate(c->up_ssl);
    EVP_PKEY *leaf_key; X509 *leaf;
    hsm_sign_leaf_cached(name, up_leaf, &leaf_key, &leaf);   // HSM 호출
    SSL_use_certificate(s, leaf);
    SSL_use_PrivateKey(s, leaf_key);
    X509_free(up_leaf);
    return SSL_TLSEXT_ERR_OK;
}

/* 5) 세션 하나를 관리하는 양방향 릴레이 — 평문은 memif로 --------*/
static int memif_sh;   // 호스트와 연결된 memif 세션 핸들 (사전 생성)

static void run_session(int client_sh) {
    SSL_CTX *srv = SSL_CTX_new(TLS_server_method());
    SSL_CTX_set_tlsext_servername_callback(srv, sni_cb);
    mitm_ctx_t ctx = {0};
    SSL *a = SSL_new(srv);
    SSL_set_ex_data(a, 0, &ctx);
    SSL_set_bio(a, vcl_bio_new(client_sh), vcl_bio_new(client_sh));
    if (SSL_accept(a) <= 0) return;     // 핸드셰이크 실패 → drop

    /* 양방향 펌프: 평문은 반드시 호스트를 거쳐 돌아온다 */
    unsigned char buf[16 * 1024];
    for (;;) {
        int n;
        n = SSL_read(a, buf, sizeof buf);               // client → plaintext
        if (n > 0) memif_send(memif_sh, client_sh, DIR_A2B, buf, n);
        int m = memif_recv(memif_sh, client_sh, DIR_B2A, buf, sizeof buf);
        if (m > 0) SSL_write(a, buf, m);                // 호스트→client 재암호
        n = SSL_read(ctx.up_ssl, buf, sizeof buf);      // origin → plaintext
        if (n > 0) memif_send(memif_sh, client_sh, DIR_B2A, buf, n);
        m = memif_recv(memif_sh, client_sh, DIR_A2B, buf, sizeof buf);
        if (m > 0) SSL_write(ctx.up_ssl, buf, m);       // 호스트→origin 재암호
    }
}

int main(void) {
    vppcom_app_create("dpu-ssli");
    int listen_sh = vppcom_session_create(VPPCOM_PROTO_TCP, 0);
    vppcom_endpt_t ep = { .is_ip4 = 1, .port = htons(443) };   // 0.0.0.0:443
    vppcom_session_bind(listen_sh, &ep);
    vppcom_session_listen(listen_sh, 1024);
    memif_sh = memif_open("/var/run/vpp/ssli-pipe.sock");

    for (;;) {
        int client_sh = vppcom_session_accept(listen_sh, NULL, 0);
        spawn(run_session, client_sh);    // 워커 스레드/이벤트 루프
    }
}

6.5.3 Host 측 골격 — Plain TCP Forwarder

호스트 쪽은 "memif에서 평문 바이트를 받아, 검사한 뒤, 다시 memif로 돌려보내는" 한 쌍의 루프만 있으면 됩니다. 여기서 OpenSSL은 필요 없고, VCL도 memif와 결합된 최소 기능만 쓰면 되므로 코드가 훨씬 단순합니다.

/* host_fwd.c — 호스트 측 plain TCP 포워더/검사기
 * DPU에서 넘어온 평문에 DLP/IDS를 적용한 뒤 그대로 돌려보낸다. */
#include <vppcom.h>
#include "ssli_proto.h"     // {conn_id, dir, len} 메타 헤더 정의

typedef struct session_state {
    uint64_t conn_id;
    char sni[256];
    enum { ALLOW, BLOCK, QUARANTINE } verdict;
} session_state_t;

static session_state_t *lookup_or_create(uint64_t conn_id);

static void on_memif_frame(const ssli_hdr_t *h, const uint8_t *plain, size_t len) {
    session_state_t *s = lookup_or_create(h->conn_id);

    /* 1) L7 훅 — DLP/IDS/카테고리 필터링 순차 적용 */
    if (!dlp_scan(plain, len, s))        { s->verdict = BLOCK; goto send_rst; }
    if (!ids_match(plain, len, s))       { s->verdict = BLOCK; goto send_rst; }
    if (!category_allow(s->sni))         { s->verdict = BLOCK; goto send_rst; }

    /* 2) 통과 → 같은 바이트를 같은 방향으로 되돌려 DPU 재암호화 */
    ssli_hdr_t out = { .conn_id = h->conn_id, .dir = h->dir, .len = len };
    memif_send_hdr_and_payload(&out, plain, len);
    return;

send_rst:
    /* 3) 차단 → DPU에 RST 지시, 로그/SIEM 전송 */
    ssli_ctrl_t rst = { .conn_id = h->conn_id, .op = SSLI_OP_RST };
    memif_send_ctrl(&rst);
    siem_log_block(s);
}

주목할 점 세 가지입니다.

• 호스트는 키를 모른다 — 호스트 프로세스는 평문을 보지만 CA 개인키나 leaf 개인키는 전혀 갖지 않습니다. 호스트가 탈취되어도 과거/미래 TLS 세션을 복호화할 능력이 없습니다. 이것이 "키 격리"의 구체적 의미입니다.
• 검사 루프는 단방향 판정만 한다 — 호스트는 통과/차단만 돌려주고, 실제 바이트 조작(예: 응답 헤더 재작성)은 가급적 하지 않습니다. 바이트를 수정하면 DPU 측 SSL_write가 재암호화는 해 주지만 HTTP/2·HTTP/3 프레이밍 오류를 유발하기 쉽습니다. 조작이 꼭 필요하면 별도 L7 게이트웨이를 호스트에 두고, 거기서 HTTP 파서 위에서 수정하는 것이 안전합니다.
• 제어 채널은 RST만으로 충분 — 차단은 "그 conn_id의 SSL을 끊어라"는 한 비트만 DPU에 전달하면 됩니다. 이걸 받은 DPU는 Session A/B 양쪽에 SSL_shutdown()을 호출하고, 필요하면 Alert를 클라이언트에 전달합니다.

6.5.4 한 요청의 바이트 워크 — 누가 언제 무엇을 들고 있는가

HTTPS GET 하나가 이 파이프라인을 지나는 동안 어떤 주체가 어떤 형태의 데이터를 들고 있는지를 표로 정리하면, 왕복 모델의 보안 특성이 직관적으로 보입니다.

이 표가 말하는 보안 특성은 분명합니다. 호스트 탈취의 피해 범위는 "탈취가 지속되는 동안 해당 호스트를 지나는 세션의 평문"으로 한정되며, 과거 트래픽 복호화·CA 위조·새 leaf 발급은 모두 불가능합니다. 반대로 DPU 탈취는 모든 것을 잃지만, DPU는 별도의 보드·별도의 OS·최소 공격면을 갖도록 관리되므로 호스트보다 침해 난이도가 한 단계 높습니다. 이것이 "호스트를 믿지 않는" 설계의 구체적 의미입니다. 1번 소절에서 언급한 B 모드/C 모드의 보안적 근거가 이 표로 설명됩니다.

6.5.5 왕복 모델에서 흔히 빠지는 함정

7. 성능 특성과 운영 포인트

8. 패킷 워크 기초 — 호스트 경로 vs DPU 경로

DPU를 처음 접할 때 가장 헷갈리는 부분이 "같은 패킷이 어디를 거쳐 어디로 가는가"입니다. 먼저 "호스트 CPU에 VPP가 있는 평범한 구성"과 "DPU Arm에 VPP가 있는 구성"을 같은 패킷 하나에 대해 나란히 비교해 보는 것이 이해의 출발점입니다. 두 경로가 왜 다른지만 분명하게 잡으면, 이후의 모든 "오프로드 최적화"는 이 그림의 어느 구간을 짧게 만드느냐의 이야기로 환원됩니다.

9. TLS 1.3 핸드셰이크 단계별 트레이스

SSL Inspection on DPU에서 가장 설명하기 어려운 부분이 핸드셰이크입니다. "클라이언트↔DPU"와 "DPU↔원서버"라는 두 개의 핸드셰이크가 동시에 진행되면서 서로의 결과에 의존하기 때문입니다. 아래는 실제 VPP/OpenSSL 구현을 기준으로 TLS 1.3 한 세션이 시작부터 첫 응용 데이터까지 어떻게 흐르는지를 단계별로 풀어쓴 것입니다.

[클라이언트]                [DPU VPP (SSL Inspector)]             [원서버]

① ─── TCP SYN ──────────▶  ┌───────────────────────┐
                            │ dpdk-input            │
                            │ ip4-input/lookup      │
                            │ tcp-input → LISTEN    │
                            │   downstream_tcp      │
                            └───────────────────────┘
② ◀────── SYN/ACK ────────┤  (DPU가 SYN 대신 응답)

③ ─── ClientHello (SNI) ─▶  ┌───────────────────────┐
                            │ tls-rx 노드           │
                            │ ClientHello 파싱      │
                            │ → SNI="api.x.com"     │
                            │ → ALPN="h2"           │
                            └─────────┬─────────────┘
                                      │
                                      │ (a) 업스트림 해석
                                      │      dns 조회 또는 설정된 upstream policy
                                      │ (b) 업스트림 TCP 접속 시작 (비동기)
                                      ▼
                            ┌───────────────────────┐
                            │ upstream_tcp (SYN) ──────────────────▶  ④
                            │   (DPU 소스 IP로)     │
                            └───────────────────────┘
                                      │                                ⑤ ◀── SYN/ACK
                                      │
                            ┌───────────────────────┐
                            │ upstream_tls 시작     │   ⑥ ────── ClientHello (진짜 SNI) ──▶
                            │ (OpenSSL ctx A)       │   ⑦ ◀── ServerHello + Cert + Fin ──
                            │ 서버 cert 검증        │
                            │   (CT / pinning)      │
                            └─────────┬─────────────┘
                                      │
                                      │ (c) 서버 cert OK → 내부 CA로
                                      │     "api.x.com"용 임시 leaf cert 서명
                                      │     (HSM의 PKCS#11 C_Sign)
                                      ▼
                            ┌───────────────────────┐
                            │ downstream_tls 응답   │
                            │ (OpenSSL ctx B)       │
                            │   ServerHello+임시cert│
                            └─────────┬─────────────┘
⑧ ◀── ServerHello+Cert ───┤
⑨ ───── Client Finished ─▶  ┌───────────────────────┐
                            │ 양쪽 모두 Finished    │
                            │ → application key     │
                            │   install (ctx A,B)   │
                            │ → 비동기 crypto 엔진  │
                            │   에 세션 등록        │
                            └───────────────────────┘

⑩ ─── 첫 Application Data ▶ (downstream record)
                            ┌───────────────────────┐
                            │ crypto-dispatch       │
                            │  → mlx5_crypto decrypt│
                            │  → 평문 vlib 버퍼     │
                            │  → http-parse → 정책  │
                            │  → crypto-dispatch    │
                            │  → mlx5_crypto encrypt│
                            │  → upstream record    │────── Application Data ──▶ ⑪

10. 동적 leaf 인증서 생성과 cert cache

SSL Inspection의 숨은 비용은 핸드셰이크마다 cert를 새로 서명하는 것입니다. TLS 1.3 핸드셰이크 한 번당 공개키 서명 한 번을 HSM에 요청하면 HSM이 곧 병목이 됩니다. 이를 피하기 위해 모든 성숙한 SSL Inspection 구현은 (SNI, 업스트림 cert fingerprint) → leaf cert의 캐시를 둡니다. VPP에 플러그인을 직접 올릴 때도 이 구조가 그대로 필요합니다.

/* plugins/ssli/ssli_cert_cache.h — 개념 단순화 버전 */
typedef struct {
    u8  sni[256];               /* 클라이언트가 보낸 SNI */
    u8  upstream_spki[32];      /* 업스트림 서버 공개키 SHA-256 */
    f64 not_after;                /* 캐시 만료 (업스트림 cert와 동기) */
    X509 *leaf;                    /* 서명 완료된 DER */
    EVP_PKEY *leaf_key;            /* leaf에 대응되는 DPU 소유 개인키 */
} ssli_cert_entry_t;

ssli_cert_entry_t *
ssli_cert_lookup_or_mint (const char *sni,
                          X509 *upstream_cert,
                          X509 *ca, EVP_PKEY *ca_key_pkcs11)
{
    u8 spki_hash[32];
    X509_pubkey_digest(upstream_cert, EVP_sha256(), spki_hash, NULL);

    /* 1) (sni, spki) 로 해시 조회 — hit이면 공개키 서명 0회 */
    ssli_cert_entry_t *e = hash_find(ssli_cc, sni, spki_hash);
    if (e && e->not_after > now_secs())
        return e;

    /* 2) miss → 새 leaf를 만든다. 원서버 cert의 SAN/CN/NotAfter를 복제 */
    e = pool_get_zero(ssli_cc->pool);
    e->leaf     = X509_new();
    X509_set_subject_name(e->leaf, X509_get_subject_name(upstream_cert));
    X509_add_ext(e->leaf,
                 X509v3_copy_san(upstream_cert), -1);
    X509_set_notAfter(e->leaf, X509_get_notAfter(upstream_cert));
    X509_set_issuer_name(e->leaf, X509_get_subject_name(ca));

    /* 3) leaf 전용 키는 DPU가 자체 생성 — 업스트림 서버 키가 아님을 보장 */
    e->leaf_key = EVP_PKEY_new();
    EVP_PKEY_keygen(ctx, &e->leaf_key);              /* ECDSA P-256 */
    X509_set_pubkey(e->leaf, e->leaf_key);

    /* 4) 서명만 HSM에 위임 — ca_key_pkcs11은 pkcs11 engine을 통한 referencing key */
    X509_sign(e->leaf, ca_key_pkcs11, EVP_sha256());

    memcpy(e->sni, sni, strlen(sni));
    memcpy(e->upstream_spki, spki_hash, 32);
    e->not_after = X509_get_notAfter_double(upstream_cert);

    hash_set(ssli_cc, sni, spki_hash, e);
    return e;
}

11. 세션 계층 배선 — VPP 코드 관점의 연결점

실제 VPP에서 SSL Inspection 플러그인을 붙이는 위치는 세션 계층(session layer)입니다. src/vnet/session이 제공하는 app listener/segment manager 인프라를 그대로 사용하면, TCP/TLS 프로토콜 기계는 건드리지 않고 "복호화된 바이트스트림을 받는 애플리케이션" 역할로 붙을 수 있습니다.

/* plugins/ssli/ssli_session.c — 핵심 콜백만 */

static session_cb_vft_t ssli_session_cb = {
    .session_accept_callback    = ssli_accept_cb,     /* 클라이언트 세션 accept */
    .session_connected_callback = ssli_connected_cb,  /* 업스트림 connect 완료 */
    .builtin_app_rx_callback    = ssli_rx_cb,         /* 복호화된 바이트 도착 */
    .session_disconnect_callback= ssli_close_cb,
    .session_reset_callback     = ssli_reset_cb,
};

/* 1) ClientHello에서 SNI가 뽑히는 즉시 업스트림 connect를 건다 */
static int
ssli_accept_cb (session_t *s)
{
    ssli_flow_t *f = ssli_flow_new();
    f->down_session = session_handle(s);

    /* SNI는 TLS plugin이 미리 opaque에 저장해 둠 */
    u8 *sni = tls_ctx_get_sni(s);
    strncpy(f->sni, (char*)sni, sizeof(f->sni));

    /* 정책 평가 — bypass / block / inspect */
    if (ssli_policy_bypass(f->sni))
        return ssli_handoff_to_splice(s);

    /* inspect: 업스트림 비동기 connect 발행 */
    vnet_connect_args_t a = {
        .app_index  = ssli_main.app_index,
        .sep_ext    = { .is_ip4 = 1, .ip = ssli_resolve(f->sni),
                        .port = 443, .transport_proto = TRANSPORT_PROTO_TLS },
        .api_context= f->id,                          /* 콜백에 돌려받음 */
    };
    return vnet_connect(&a);
}

/* 2) 업스트림 TLS가 완성되면 두 세션을 하나의 flow로 바인딩 */
static int
ssli_connected_cb (u32 app_wrk, u32 api_ctx, session_t *s, u32 err)
{
    ssli_flow_t *f = ssli_flow_get(api_ctx);
    if (err) return ssli_block(f, err);

    f->up_session = session_handle(s);
    ssli_mint_leaf_cert(f);          /* 앞 절의 cert cache 호출 */
    ssli_start_downstream_tls(f);    /* 이제서야 클라이언트 Server*      */
    return 0;
}

/* 3) 복호화된 바이트가 들어오면 정책 매칭 후 반대 세션으로 fwd */
static int
ssli_rx_cb (session_t *s)
{
    ssli_flow_t *f = ssli_session_to_flow(s);
    svm_fifo_t  *rx = s->rx_fifo;

    u32 n = svm_fifo_max_dequeue_cons(rx);
    while (n)
    {
        u8 chunk[4096];
        u32 got = svm_fifo_peek(rx, 0, 4096, chunk);

        /* DPI 엔진으로 평가 — 매치 시 로그/차단 */
        ssli_dpi_scan(f, chunk, got);

        /* 반대쪽 세션의 TX fifo로 전달 — 복사 회피 가능 시 splice */
        session_t *peer = session_get_from_handle(
            (s == ssli_down(f)) ? f->up_session : f->down_session);
        app_worker_enqueue(peer, chunk, got);

        svm_fifo_dequeue_drop(rx, got);
        n -= got;
    }
    return 0;
}

12. 그래프 노드 워크스루 — 패킷이 실제로 밟는 노드들

위의 코드와 핸드셰이크를 "VPP 노드 그래프" 기준으로 한 번 더 보는 것이 디버깅에 결정적입니다. show trace에서 실제로 나타나는 노드 이름들을 기준으로, 한 흐름이 방문하는 노드 열을 정리했습니다. 각 노드에서 어떤 상태가 바뀌는지 메모가 붙어 있습니다.

이 표는 "어디서 무엇이 돌아가는가"에 대한 직접적인 답이기도 합니다. 11·12·14번만 DPU 가속기 영역이고 나머지는 모두 Arm 코어 노드입니다. 따라서 성능 병목은 둘 중 하나에서만 나타납니다 — Arm 그래프가 느리거나(대부분 배치가 깨진 경우), 가속기 큐가 꽉 찬 경우(enqueue/dequeue가 CPU를 잡아먹는 경우). 이 이분법이 튜닝 작업을 단순하게 만듭니다.

13. 관측과 디버깅 — 어디를 어떻게 보는가

# 1) 세션 상태 — 양쪽 세션이 짝지어져 있는지 확인
dpu# show ssli sessions                # 플러그인 CLI
  flow-id  sni             down-state   up-state    policy   leaf-cache
  42       api.example.com ESTABLISHED  ESTABLISHED inspect  HIT
  43       cdn.example.net ESTABLISHED  ESTABLISHED bypass   (splice)

# 2) async crypto 큐 — enqueue/dequeue 잔량, 오류 카운터
dpu# show crypto async status
  thread 0  dispatch-node active
            frames in-flight: 48
            enqueued: 120394   dequeued: 120346
            errors:   0

# 3) cryptodev 디바이스 레벨 통계
dpu# show dpdk cryptodev
  cryptodev 0  mlx5_crypto
    qp 0  enqueue 482371   dequeue 482301   err 0   avg_burst 31

# 4) 실제 패킷 추적 — 노드 열로 확인
dpu# clear trace
dpu# trace add dpdk-input 200
dpu# # 테스트 클라이언트에서 curl https://api.example.com
dpu# show trace
  Packet 1
   01: dpdk-input ...
   02: ethernet-input
   03: ip4-input
   04: ip4-lookup
   05: ip4-local
   06: tcp4-input-nolookup
   07: session-queue
   08: tls-rx sni="api.example.com"
   09: ssli-accept flow=42 policy=inspect
   ...

# 5) 감사 채널 구독 (호스트 측 분석기)
host$ socat UNIX-CONNECT:/run/vpp/ssli-audit.sock -
  {"ts":..., "sni":"api.example.com", "host":"api.example.com",
   "url":"/v1/users", "verdict":"allow", "bytes_down":1843, "bytes_up":206}

# 6) PCAP으로 잘라 보기 — "평문이 DPU 경계를 넘지 않았는지" 검증
dpu# pcap trace rx tx max 1000 intfc uplink0 file /tmp/uplink.pcap
  ↑ uplink0은 외부 방향 — 여기에 평문이 나타나면 설정 버그

14. 실습 랩 스켈레톤 — 최소 재현 환경

실제로 한 번 재현해 보지 않으면 이 절의 내용이 머리에 남지 않습니다. 아래는 BlueField-2 또는 x86에서 소프트웨어 cryptodev(crypto_aesni_mb 또는 crypto_openssl)로 대체해 돌릴 수 있는 최소 랩 스켈레톤입니다. 실제 DPU가 없어도 동일한 코드 경로를 밟을 수 있기 때문에 학습용으로 먼저 이 구성을 돌려 보시기 바랍니다.

# 토폴로지
#
#   [ client ]  ──▶  veth0  ──▶  (VPP) ──▶  veth1  ──▶  [ origin nginx ]
#                                  │
#                                  └─▶  memif(ssli-audit.sock) ──▶ [analyzer]
#
# 가짜 DPU 대신 호스트의 리눅스 namespace 두 개를 사용

# 0) namespace와 veth
$ sudo ip netns add cli
$ sudo ip netns add srv
$ sudo ip link add veth-cli type veth peer name veth-vpp-c
$ sudo ip link add veth-srv type veth peer name veth-vpp-s
$ sudo ip link set veth-cli netns cli
$ sudo ip link set veth-srv netns srv
$ sudo ip -n cli addr add 10.0.0.2/24 dev veth-cli
$ sudo ip -n srv addr add 10.0.1.2/24 dev veth-srv
$ sudo ip -n cli link set veth-cli up
$ sudo ip -n srv link set veth-srv up

# 1) VPP 구동 (호스트에서, 단 cryptodev는 SW)
$ sudo vpp unix { interactive } \
           dpdk { no-pci vdev crypto_openssl0 } \
           plugins { plugin tlsopenssl_plugin.so { enable } }

# 2) 인터페이스 생성과 주소
vpp# create host-interface name veth-vpp-c
vpp# create host-interface name veth-vpp-s
vpp# set interface ip address host-veth-vpp-c 10.0.0.1/24
vpp# set interface ip address host-veth-vpp-s 10.0.1.1/24
vpp# set interface state host-veth-vpp-c up
vpp# set interface state host-veth-vpp-s up

# 3) 테스트 CA 준비 (실습 전용, 절대 운영 환경에 쓰지 마세요)
$ openssl ecparam -genkey -name prime256v1 -out /tmp/ca.key
$ openssl req -x509 -new -key /tmp/ca.key -subj '/CN=SSLI Lab CA' \
              -days 30 -out /tmp/ca.pem

# 4) SSL Inspection 활성화 (플러그인이 있는 경우)
vpp# tls ca-cert file /tmp/ca.pem
vpp# tls ca-key  file /tmp/ca.key
vpp# ssli listener add 10.0.0.1:443 upstream 10.0.1.2:443 dynamic-cert on
vpp# set crypto async handler aes-128-gcm openssl
vpp# set crypto async dispatch on

# 5) origin에 nginx와 테스트 컨텐츠
$ sudo ip netns exec srv nginx -c /tmp/nginx.conf   # TLS 서버

# 6) 클라이언트 테스트
$ sudo ip netns exec cli curl -v --cacert /tmp/ca.pem https://10.0.0.1/
  ↑ 브라우저 신뢰 체인 검증, CA 주입이 필요한 케이스 확인

# 7) 검증 체크리스트
vpp# show ssli sessions       # down/up 둘 다 ESTABLISHED 여야 함
vpp# show trace               # ssli-accept, ssli-rx 노드가 보여야 함
vpp# pcap trace rx tx intfc host-veth-vpp-s file /tmp/upstream.pcap
  분석: upstream.pcap에는 평문 HTTP 헤더가 없어야 함 (재암호화 검증)

15. 한 장 요약

DPU에서의 VPP는 "Arm 코어 + 도메인 가속기 + 자체 OS"라는 세 축을 기반으로, 호스트 경험의 대부분을 aarch64로 옮기는 작업입니다. SSL Inspection 시나리오에서는 ① AEAD를 cryptodev로 오프로드하고, ② 핸드셰이크와 정책 매칭은 Arm VPP가 처리하며, ③ CA 개인키는 HSM/TPM에 격리하고, ④ 복호화된 평문은 DPU 경계 밖으로 나가지 않도록 감사 채널을 단방향·메타데이터 한정으로 두는 것이 기본 공식입니다. 이 공식만 지키면 DPU가 제공하는 "호스트 독립적 보안 경계"라는 이점을 그대로 얻을 수 있습니다.

관련 문서

이 주제와 관련된 다른 문서를 더 깊이 이해하고 싶다면 다음을 참고하시기 바랍니다.

• 운영 · 플랫폼 · 확장 — 본 문서의 모태가 되는 운영 페이지
• TCP/TLS 프록시 · SSL Inspection — SSL Inspection의 일반 설계
• 보안과 터널링 — SSL Inspection 보안 통합과 거버넌스
• 호스트 스택 개요 — 호스트 스택·세션 계층 개요
• TLS — TLS 엔진·인증서·성능 심화
• VPP — QUIC · HTTP/3 — QUIC/HTTP3 심화
• 데이터 경로 (L2~L4)
• 기초와 아키텍처

오픈소스 코드 인용 고지

코드 블록 내 주석에 원본 파일 경로가 표기된 부분은 해당 프로젝트 소스 코드에서 발췌·간략화한 것입니다. 전체 소스 코드는 위 공식 저장소에서 확인하시기 바랍니다.