Booil Jung

UDP 통신 보안 프레임워크에 대한 종합 분석

본 보고서는 사용자 데이터그램 프로토콜(User Datagram Protocol, UDP)에 내재된 보안 문제점을 심층적으로 분석하고, 이를 완화하기 위해 설계된 최신 보안 프레임워크에 대한 상세한 평가를 제공한다. 보고서는 먼저 UDP의 비연결성, 비신뢰성 등 핵심적인 아키텍처 특성이 어떻게 플러딩(flooding), 반사(reflection) 및 증폭(amplification) 공격과 같은 광범위한 위협의 근본 원인이 되는지를 해부한다.

분석의 핵심은 UDP 통신을 보호하기 위한 세 가지 주요 보안 프로토콜, 즉 DTLS(Datagram Transport Layer Security), IPsec(Internet Protocol Security), QUIC(Quick UDP Internet Connections)에 대한 심층 탐구에 있다. 각 프로토콜의 작동 메커니즘, 성능 특성, 그리고 이상적인 활용 사례를 상세히 검토한다. 나아가, 온라인 게임과 같이 표준 프로토콜이 부적합할 수 있는 특수한 환경에서 사용되는 애플리케이션 중심의 보안 패러다임도 탐색한다.

성능, 보안 태세, 운영 복잡성을 기준으로 한 비교 분석을 통해 특정 사용 사례에 가장 적합한 기술을 선택할 수 있는 의사결정 프레임워크를 제시한다. 또한, 클라우드 기반 분산 서비스 거부(DDoS) 완화 서비스 및 인터넷 서비스 제공자(ISP) 수준의 필터링을 포함한 필수적인 인프라 수준의 방어 체계에 대해서도 상세히 다룬다.

마지막으로, 양자내성암호(Post-Quantum Cryptography, PQC)의 부상과 전송 계층 표준의 진화 등 미래 전망을 조망하며, UDP 기반 통신을 보호하기 위한 다계층적이고 전략적인 권고안을 제시함으로써 본 보고서는 UDP 보안을 책임지는 아키텍트, 엔지니어, 관리자를 위한 포괄적인 전략 가이드 역할을 수행하고자 한다.

본 섹션에서는 UDP의 핵심적인 특징인 속도와 단순성이 어떻게 보안 취약점의 직접적인 원인이 되는지를 근본적으로 탐구한다. 프로토콜의 기본 설계 원칙에서 시작하여, 이러한 설계적 선택이 위협 행위자들에게 어떻게 악용되는지에 대한 상세한 분석으로 나아간다.

사용자 데이터그램 프로토콜(UDP)은 전송 계층 프로토콜로서, 연결 설정, 순서 보장, 흐름 제어, 혼잡 제어와 같은 TCP(Transmission Control Protocol)의 신뢰성 보장 메커니즘을 의도적으로 배제한 비연결성, 비신뢰성 프로토콜로 정의된다.1 UDP 헤더는 출발지/목적지 포트, 길이, 그리고 선택적 체크섬(checksum)만으로 구성된 8바이트의 최소한의 구조를 가지며, 이로 인해 오버헤드가 매우 낮다.1

이러한 설계 철학은 DNS(Domain Name System), VoIP(Voice over IP), 온라인 게임과 같이 시간에 민감한 애플리케이션에 UDP를 이상적인 선택으로 만든다.2 이들 애플리케이션에서는 지연된 패킷을 기다리는 것보다 손실된 패킷을 무시하는 것이 전체적인 서비스 품질에 더 유리하기 때문이다. 결과적으로 UDP는 패킷 손실, 순서 뒤바뀜과 같은 신뢰성 문제에 대한 처리 책임을 온전히 애플리케이션 계층으로 전가한다.1 이는 UDP 보안을 논의하는 데 있어 모든 후속 분석의 기초가 되는 핵심적인 아키텍처 결정이다.

기능	전송 제어 프로토콜 (TCP)	사용자 데이터그램 프로토콜 (UDP)
연결 모델	연결 지향 (Connection-Oriented)	비연결성 (Connectionless)
신뢰성	높음 (패킷 재전송 및 확인 응답)	낮음 (최선 노력 전송)
순서 보장	보장 (시퀀스 번호 사용)	보장 안 함
흐름 제어	지원 (슬라이딩 윈도우)	지원 안 함
혼잡 제어	지원 (AIMD, Slow Start 등)	지원 안 함
헤더 크기	20바이트 (옵션 제외)	8바이트
오버헤드	높음	낮음
핸드셰이크	3-way 핸드셰이크 필요	불필요
주요 사용 사례	웹 (HTTP/HTTPS), 이메일 (SMTP), 파일 전송 (FTP)	DNS, VoIP, 실시간 스트리밍, 온라인 게임

UDP의 프로토콜적 특징과 보안적 결함 사이에는 명확한 인과 관계가 존재한다. 연결 설정 과정의 부재는 수신자의 준비 상태를 확인하지 않고 데이터를 전송함을 의미하며 2, 이는 UDP 데이터그램의 출발지 IP 주소를 위조(spoofing)하는 것을 매우 용이하게 만든다.7 수신 시스템은 프로토콜 수준에서 출발지 IP의 정당성을 검증할 내장된 메커니즘을 가지고 있지 않다.7

이러한 구조적 특성은 다음과 같은 직접적인 공격 경로를 형성한다:

1. 비연결성 설계 –» 핸드셰이크/상태 검증 부재 –» IP 스푸핑의 용이성.
2. IP 스푸핑의 용이성 –» 반사 및 증폭 공격의 가능성.
3. 흐름/혼잡 제어 부재 –» 대규모 플러딩 공격에 대한 취약성.
4. 내장된 암호화/인증 부재 –» 데이터 변조 및 도청에 대한 무방비 상태.

이처럼 UDP의 취약점은 우연한 결함이 아니라, 속도와 단순성을 극대화하기 위한 의도적인 설계의 필연적인 결과이다. TCP가 SYN 쿠키나 시퀀스 번호와 같은 상태 기반의 방어 메커”니즘을 내재하고 있는 것과 달리, UDP는 프로토콜 자체적으로는 이러한 공격에 대해 무방비 상태이다. 따라서 UDP를 보호하는 것은 프로토콜을 “수정”하는 것이 아니라, 그 위에 보안을 “계층화”하는 접근 방식을 요구하게 된다.

앞서 식별된 취약점을 악용하는 주요 공격 벡터는 다음과 같이 체계적으로 분류할 수 있다.

UDP 플러딩은 공격자가 대상 서버의 임의 포트로 대량의 UDP 패킷을 전송하는 서비스 거부(DoS) 공격이다.9 서버가 특정 포트에서 수신 대기 중인 애플리케이션이 없는 UDP 패킷을 받으면, 해당 패킷을 처리하고 “Destination Unreachable” ICMP 응답 메시지를 생성해야 한다.9 이 과정은 서버의 CPU 및 네트워크 대역폭과 같은 자원을 소모시키며, 결국 자원 고갈로 이어져 정상적인 사용자에 대한 서비스 거부를 유발한다.9 이러한 공격은 LOIC과 같은 간단한 도구를 통해 쉽게 실행될 수 있으며, 봇넷을 이용해 분산 서비스 거부(DDoS) 공격으로 확장될 수 있다.9 이 공격의 효과는 단순히 대역폭 포화에만 있는 것이 아니라, 각각의 악성 패킷에 대해 운영체제가 예외 처리 프로세스를 수행하도록 강제함으로써 계산 자원을 고갈시키는 데 있다.

이 공격 유형은 IP 스푸핑과 잘못 설정된 제3자 서버(반사체)를 결합하여 공격의 규모를 극대화하고 공격자의 신원을 은폐한다. 공격자는 피해자의 IP를 위조된 출발지 주소로 사용하여 반사체에 요청을 보내고, 반사체는 요청보다 훨씬 큰 응답을 피해자에게 보낸다.13

• DNS 증폭 공격: 공격자는 공개된 DNS 리졸버에 “ANY”와 같은 작은 DNS 쿼리를 보내고, 이는 방대한 양의 레코드를 포함하는 큰 응답을 생성하여 피해자에게 전달된다. 증폭 계수는 50배 이상에 달할 수 있다.13
• Memcached 증폭 공격: 인터넷에 노출된 채 잘못 설정된 Memcached 서버(UDP 포트 11211)를 악용하는 이 공격은 특히 파괴적이다. 작은 요청이 최대 50,000배까지 증폭될 수 있으며, 이는 GitHub에 대한 1.3 Tbps 규모의 공격과 같은 대규모 침해 사고로 이어졌다.14 이 취약점(CVE-2018-1000115)은 구버전에서 UDP 지원이 기본적으로 활성화되어 있고 인증 절차가 없기 때문에 발생한다.19
• 기타 벡터: RADIUS와 같은 다른 프로토콜들도 UDP에 의존하기 때문에 유사한 반사 및 증폭 공격에 취약한 것으로 확인되었다.22

이러한 증폭 공격의 효과는 UDP 자체의 결함뿐만 아니라, 인터넷 생태계 전반에 걸쳐 존재하는 잘못 설정된 서버들(공개 DNS 리졸버, 노출된 Memcached 서버 등)이라는 시스템적 문제에 기인한다. UDP의 취약성은 이러한 더 큰 분산 위협을 촉발하는 기폭제 역할을 한다. 즉, 공격 표면은 피해자의 인프라에 국한되지 않고, 인터넷상에 존재하는 모든 취약한 UDP 서버의 총합으로 확장된다.

UDP는 데이터 변조(무결성), 도청(기밀성), 재전송 공격에 대한 어떠한 보호 장치도 제공하지 않는다. IPv4에서 선택 사항인 체크섬은 전송 중 발생한 오류를 검증할 뿐, 악의적인 수정을 탐지하지는 못한다.1 순서 번호 메커니즘이 없기 때문에 공격자는 패킷을 가로채서 재전송(replay)할 수 있다. 이러한 근본적인 한계는 DTLS, IPsec과 같은 상위 계층 보안 프로토콜의 필요성을 명확히 보여준다.

공격 분류	특정 공격 벡터	악용된 UDP 취약점	주요 영향
볼류메트릭	UDP 플러드, UDP 단편화 공격	흐름/혼잡 제어 부재	자원 고갈, 대역폭 포화
반사/증폭	DNS 증폭, Memcached DRDoS, RADIUS 공격	비연결성 (IP 스푸핑 가능)	막대한 대역폭 포화, 서비스 불능
무결성/스푸핑	Snork 공격, UDP Loop-back	비연결성, 인증 부재	내부 자원 고갈, 네트워크 루프
데이터 침해	도청, 중간자 공격	내장된 암호화 부재	데이터 유출, 세션 하이재킹

본 섹션에서는 검증된 보안 모델인 TLS를 UDP 환경에 직접적으로 적용한 DTLS를 소개한다. DTLS가 비신뢰성 전송이라는 제약 조건 하에서 어떻게 UDP의 보안 문제를 해결하는지에 초점을 맞추어, 그 아키텍처와 핵심 메커니즘을 심층적으로 분석한다.

DTLS(Datagram Transport Layer Security)는 데이터그램 프로토콜을 위한 통신 보안을 제공하며, 도청, 변조, 메시지 위조를 방지하도록 설계된 프로토콜이다.23 이는 스트림 지향적인 TLS 프로토콜에 기반하며 유사한 수준의 보안 보장을 목표로 한다.23 TLS는 TCP와 같은 신뢰성 있는 전송 채널을 전제로 하므로 UDP에는 직접 적용할 수 없다. DTLS는 SIP(Session Initiation Protocol)나 온라인 게임과 같이 널리 사용되는 UDP 기반 애플리케이션을 위해 이러한 간극을 메우기 위해 탄생했다.23

DTLS는 새로운 프로토콜이라기보다, TLS의 상태 기반 순차적 핸드셰이크를 UDP의 비상태, 비순차적 특성에 맞게 변용한 영리한 공학적 적응으로 이해할 수 있다. DTLS의 핵심적인 기여는 보안 세션을 설정하는 핸드셰이크 단계에 한정하여 최소한의 신뢰성을 부여하는 것이다. 일단 보안 컨텍스트가 수립되면, 애플리케이션 데이터는 암호화된 상태로 표준 UDP를 통해 전송될 수 있다.

TLS의 핸드셰이크는 메시지가 정해진 순서대로 도착해야 하는 엄격한 “잠금 단계(lock-step)” 프로세스다.23 DTLS는 UDP의 패킷 손실 및 순서 뒤바뀜 문제를 극복하기 위해 핸드셰이크에 다음과 같은 메커니즘을 추가했다.

• 핸드셰이크 신뢰성 확보:
  • 재전송 타이머: 핸드셰이크 메시지가 손실될 경우를 대비해 간단한 타이머를 사용하여 메시지를 재전송한다.23
  • 시퀀스 번호: 각 핸드셰이크 메시지에 고유한 시퀀스 번호를 할당하여, 수신 측에서 메시지 순서를 재조정하고 누락된 메시지가 도착할 때까지 후속 메시지를 큐에 보관할 수 있도록 한다.23
• 단편화 처리: 핸드셰이크 메시지는 단일 UDP 데이터그램의 MTU(Maximum Transmission Unit)를 초과할 수 있다. 이를 해결하기 위해 DTLS는 자체 레코드 계층 내에 단편화 메커니즘을 도입하여, 큰 메시지를 여러 레코드로 분할하고 수신 측에서 재조립할 수 있게 한다.23
• 레코드 계층 적응 및 재전송 방지: DTLS 레코드 계층은 각 데이터그램을 독립적으로 처리하도록 TLS에서 수정되었다. 각 레코드에 명시적인 시퀀스 번호를 추가하여 재전송 공격(replay attack)을 방지한다. 이는 수신 측에서 슬라이딩 윈도우 비트맵을 유지하여 이미 수신된 패킷이나 오래된 패킷을 식별하고 폐기하는 방식으로 구현된다.23
• DoS 공격 방어: DTLS는 초기 핸드셰이크 과정에서 쿠키 교환 메커니즘(HelloVerifyRequest 메시지)을 포함한다. 이는 서버가 상태 정보를 할당하기 전에 클라이언트가 자신의 출발지 IP 주소에 대한 소유권을 증명하도록 강제하여, 특정 유형의 자원 고갈 DoS 공격을 완화하는 데 도움을 준다.25

이러한 추가 기능들(타이머, 시퀀스 번호, 단편화 로직)은 DTLS를 사용하는 데 따르는 “비용”으로, 순수 UDP가 제공하는 낮은 지연 시간과 단순성을 일부 희생하게 된다. 즉, DTLS를 사용하기로 한 결정은 초기 연결 설정 시의 지연과 복잡성을 감수하는 대신, 이후의 데이터 전송을 안전하게 보장받기 위한 명시적인 트레이드오프인 셈이다.

WebRTC와 같은 실시간 통신 애플리케이션은 미디어 채널의 암호화를 요구하며, 이때 DTLS는 SRTP(Secure Real-time Transport Protocol)의 키 교환을 위해 핵심적인 역할을 수행한다.27 RFC 5763과 5764에 정의된 이 아키텍처는 DTLS를 키 관리에, SRTP를 RTP 미디어 스트림의 기밀성 및 인증에 사용한다.28

DTLS-SRTP 아키텍처의 동작 흐름은 다음과 같다:

1. 초기 협상: 발신자가 DTLS 교환을 요청하는 SDP(Session Description Protocol) 파라미터를 포함한 SIP INVITE 메시지를 보낸다.28 SDP에는 인증서 지문(fingerprint)이 포함되어 시그널링과 미디어 평면의 신원을 암호학적으로 연결한다.27
2. DTLS 핸드셰이크: SIP 협상이 완료되면, 미디어 경로(UDP 포트)를 통해 양단 간에 DTLS 핸드셰이크가 수행되어 공유 비밀 키를 설정한다.27
3. SRTP 키 파생 및 미디어 전송: DTLS 핸드셰이크를 통해 생성된 공유 비밀 키는 RTP/RTCP 패킷을 암호화하고 인증하기 위한 SRTP 키를 파생시키는 데 사용된다.29 키 설정이 완료되면, 양단은 SRTP를 통해 안전하게 미디어를 교환한다.

이 사례는 현대적인 보안 UDP 애플리케이션의 하이브리드 특성을 명확히 보여준다. DTLS는 강력하고 표준화된 키 관리 기능을 제공하기 위해 연결 설정 단계에서만 사용된다. 키가 설정된 후에는, 대용량 미디어 스트림에 대해 DTLS 레코드의 패킷당 오버헤드를 피하기 위해 고도로 최적화된 SRTP로 전환된다. 이는 보안의 견고함과 성능 요구사항 사이의 균형을 맞추는 탁월한 설계 패턴이다.

DTLS는 메시지 손실, 순서 재조정, 자체 재전송 로직 등을 처리해야 하므로 TCP 기반 보안 프로토콜보다 구현이 더 복잡하며, 상태 머신 관리의 어려움을 야기한다.33 따라서 직접 구현하기보다는 OpenSSL과 같이 잘 검증된 라이브러리를 사용하는 것이 강력히 권장된다.34

DTLS 배포 시 다음과 같은 보안 강화 조치가 필수적이다:

• 프로토콜 버전 관리: DTLS 1.0 협상은 절대 금지해야 한다. 구현은 반드시 DTLS 1.2를 지원해야 하며, DTLS 1.3 지원이 권장된다.37
• 암호화 스위트 선택: NULL, RC4, 또는 수출 등급(export-grade) 암호화 스위트의 협상을 금지해야 한다. 완전 순방향 비밀성(Perfect Forward Secrecy)을 보장하기 위해 정적 RSA 키 전송 방식 대신 임시적 디피-헬만(Ephemeral Diffie-Hellman) 키 교환 방식을 사용해야 한다.37
• 인증서 관리: 중간자 공격(MITM)을 방지하기 위해 신뢰할 수 있는 인증 기관(CA)에서 발급한 유효한 인증서를 사용하고, 수신된 인증서를 철저히 검증해야 한다. 적절한 신뢰 체인 없이 자체 서명된 인증서의 사용은 피해야 한다.38 핸드셰이크 패킷 크기를 줄이기 위해 ECDSA와 같이 공개 키 표현이 작은 알고리즘을 사용하는 것이 유리하다.37
• 자원 제약 환경(IoT) 최적화: IoT 기기에서는 타원 곡선 암호(ECC)와 같이 계산 효율성이 높은 알고리즘을 선택하고, 헤더 압축을 사용하며, 세션 재개(session resumption) 기능을 활용하여 핸드셰이크 오버헤드를 최소화해야 한다.39

본 섹션에서는 전송 계층에서 네트워크 계층으로 초점을 이동하여, UDP 보안에 대한 근본적으로 다른 접근 방식인 IPsec을 제시한다. IPsec의 애플리케이션 독립적인 특성과 이것이 네트워크 아키텍처 및 관리에 미치는 영향을 중점적으로 다룬다.

IPsec(IP Security)은 네트워크 계층(Layer 3)에서 동작하는 프로토콜 스위트로서, 데이터 스트림의 각 IP 패킷을 인증하거나 암호화하여 IP 통신을 보호한다.41 IP 계층에서 작동하기 때문에 애플리케이션 수정 없이 TCP, UDP, ICMP를 포함한 모든 상위 계층 트래픽을 보호할 수 있다.44 보안 파라미터는 보안 연관(Security Association, SA)을 통해 관리되며, SA는 IKE(Internet Key Exchange) 프로토콜을 통해 협상된다.41

IPsec은 DTLS와 달리 애플리케이션을 인지하지 못하는 네트워크 중심의 솔루션이다. 이는 두 엔드포인트(호스트 또는 네트워크) 간의 모든 트래픽에 대해 투명한 보안 “담요”를 제공하며, VPN과 같은 보안 채널을 생성하는 데 이상적이다.

IPsec은 두 가지 주요 동작 모드를 제공하며, 각 모드는 패킷 구조에 뚜렷한 차이를 보인다.

• 전송 모드 (Transport Mode): IP 페이로드(예: UDP 데이터그램)만을 암호화하고, 원래의 IP 헤더는 그대로 유지한다. 이 모드는 통신 종단점과 암호화 종단점이 동일한 종단 간(end-to-end) 통신에 주로 사용된다.41
  • 패킷 구조: [Original IP Header][IPsec Header]
• 터널 모드 (Tunnel Mode): 전체 원본 IP 패킷(헤더와 페이로드 모두)을 새로운 IP 헤더를 가진 새로운 IP 패킷 내에 캡슐화한다. 이 모드는 내부 네트워크 토폴로지를 숨기기 때문에 네트워크 대 네트워크 또는 호스트 대 네트워크 통신(VPN)에 사용된다.41
  • 패킷 구조: [New IP Header][IPsec Header][Encrypted Original IP Packet]

이러한 구조적 차이는 터널 모드가 VPN 게이트웨이에 필수적인 이유를 명확히 설명해준다. “외부” 패킷은 공용 인터넷을 통해 라우팅될 수 있는 반면, “내부” 패킷의 출발지 및 목적지 주소는 비공개로 유지된다.

IPsec은 두 가지 핵심 보안 프로토콜을 제공한다:

• 인증 헤더 (Authentication Header, AH): 비연결 무결성, 데이터 발신지 인증, 재전송 방지 기능을 제공하지만, 기밀성(암호화)은 제공하지 않는다.43 AH는 IP 헤더의 불변 필드를 포함한 전체 패킷을 인증한다.
• 캡슐화 보안 페이로드 (Encapsulating Security Payload, ESP): 기밀성(암호화)을 제공하며, 선택적으로 무결성, 인증, 재전송 방지 기능도 제공할 수 있다.43

AH는 강력한 인증을 제공하도록 설계되었지만, IP 헤더를 무결성 검사에 포함시키기 때문에 IP 주소를 수정하는 NAT(Network Address Translation)와 호환되지 않는다. 이러한 제약으로 인해, 더 선호되는 기능인 암호화를 제공하고 외부 IP 헤더를 무결성 검사에서 제외하여 NAT 환경과 호환되는 ESP가 사실상의 표준 프로토콜로 자리 잡았다.

NAT는 IP 주소와 포트를 수정하기 때문에 IPsec의 무결성 검사를 깨뜨리고 IKE 협상을 방해하여 표준 IPsec과 근본적으로 호환되지 않는다. NAT-T(NAT Traversal, RFC 3947)는 IPsec (ESP) 패킷을 UDP 패킷으로 캡슐화하여 이 문제를 해결하며, 일반적으로 UDP 포트 4500을 사용한다.47

NAT-T의 작동 메커니즘은 다음과 같다:

1. NAT-T 지원 탐지: IKE 1단계(Phase 1) 동안, 양단은 벤더 ID(Vendor ID) 페이로드를 교환하여 NAT-T 지원 여부를 확인한다.47
2. NAT 존재 탐지: 이후 양단은 각자의 IP 주소와 포트의 해시값을 포함하는 NAT-D(NAT-Discovery) 페이로드를 교환한다. 송신한 해시값과 수신한 해시값을 비교하여 통신 경로상에 NAT 장치가 있는지 탐지한다.47
3. 포트 전환 및 캡슐화: NAT가 탐지되면, 양단은 IKE 및 후속 ESP 트래픽을 UDP 포트 4500으로 전환하고, ESP 패킷을 UDP 데이터그램 내에 캡슐화하여 전송한다.49

NAT-T는 거의 항상 NAT 장치 뒤에 있는 원격 사용자들이 IPsec VPN을 실질적으로 사용할 수 있게 해주는 핵심 기술이다. UDP 캡슐화는 IPsec 트래픽이 NAT 장치를 효과적으로 “터널링”하여 통과할 수 있도록 한다. 이 과정은 IPsec이라는 하위 계층 프로토콜이 상위 계층인 UDP에 의존하여 현대 네트워크에서 생존하는 역설적인 상황을 보여준다. 이는 네트워크 진화 과정에서 실용적인 해결책이 종종 아키텍처의 순수성보다 우선시됨을 시사한다.

IPsec은 보안 VPN을 구축하기 위한 사실상의 표준이다.42 터널 모드에서 IPsec은 원격 호스트와 기업 네트워크, 또는 두 기업 네트워크 간에 보안 채널을 생성하여 그 사이를 흐르는 모든 트래픽을 보호한다.44

NAT 뒤에 있는 원격 사용자의 VPN 클라이언트는 NAT-T를 포함한 IKE를 사용하여 기업 VPN 게이트웨이와 보안 터널을 설정한다. 이후 사용자의 모든 트래픽(UDP 기반 애플리케이션 포함)은 ESP-in-UDP 패킷(터널 모드)으로 캡슐화되어 인터넷을 통해 안전하게 전송된다. 이는 최종 사용자 애플리케이션의 변경 없이 포괄적인 보안 솔루션을 제공한다. 이처럼 IPsec의 가장 큰 장점인 애플리케이션 투명성은 동시에 커널 수준의 구현과 복잡한 정책 관리를 요구하는 단점이 되기도 한다. 이는 개발자가 사용자 공간 라이브러리를 통해 직접 제어할 수 있는 DTLS와 대조되는 지점이다.

본 섹션에서는 점진적 개선이 아닌 혁신적 단계로서의 QUIC을 제시한다. QUIC은 UDP 위에 신뢰성과 보안을 직접 구축하여 전송 계층을 재설계하며, 현대 웹 환경에서 TCP/TLS를 대체하는 것을 목표로 한다.

QUIC은 TCP의 한계(예: Head-of-Line 블로킹)를 극복하기 위해 UDP 위에 구축된 새로운 전송 프로토콜이다.52 이는 커널 기반의 TCP와 달리 사용자 공간(user-space)에서 구현되어, 운영체제 업데이트를 기다릴 필요 없이 빠른 프로토콜 진화가 가능하다.52 QUIC은 TCP의 전송 기능, TLS의 보안, HTTP/2의 스트림 멀티플렉싱을 단일 프로토콜로 통합하여 전체적인 통신 스택을 재구성한다.52

QUIC은 기존 프로토콜에 보안을 “추가”하는 DTLS나 IPsec과 달리, 처음부터 보안을 내장한(secure-by-default) 프로토콜이다. 이러한 사용자 공간 기반의 설계는 브라우저 공급업체와 같은 애플리케이션 개발자들이 혁신을 주도할 수 있게 하는 핵심적인 전략적 이점을 제공한다. 이는 전송 프로토콜의 개발 주기를 수십 년에서 현대 소프트웨어의 빠른 릴리스 주기로 단축시키는 패러다임의 전환을 의미한다.

QUIC은 기본적으로 암호화되며, 암호화되지 않은 버전은 존재하지 않는다.54 이는 TLS 1.3 핸드셰이크를 프로토콜에 깊숙이 통합함으로써 달성된다.53 그러나 QUIC은 DTLS처럼 단순히 TLS를 UDP 위에서 실행하는 것이 아니다. 대신, QUIC은 TLS 레코드 계층을 자체 패킷 프레이밍 메커니즘으로 대체한다.61 TLS 핸드셰이크 메시지는 QUIC의 CRYPTO 프레임 내에서 전송되며, TLS 레코드 프로토콜 대신 QUIC의 자체 패킷 보호 기능이 사용된다.61 이러한 긴밀한 통합은 암호화 핸드셰이크와 전송 핸드셰이크를 결합하여, 패킷 번호와 같은 전송 계층 메타데이터까지 암호화하고 0-RTT 연결 설정을 가능하게 하는 최적화를 이끌어낸다.

QUIC의 설계는 현대 웹 및 모바일 애플리케이션의 고질적인 문제들을 직접적으로 해결한다.

• 지연 시간 감소: 전송 및 암호화 핸드셰이크를 결합하여, QUIC은 1-RTT 연결 설정을 달성한다. 이전에 연결했던 서버에 대해서는 클라이언트가 첫 패킷에 암호화된 애플리케이션 데이터를 담아 보내는 0-RTT 연결 설정도 가능하다.54
• 스트림 멀티플렉싱 및 HOL 블로킹 제거: QUIC은 단일 연결 내에서 여러 독립적인 스트림을 허용한다. 한 스트림의 패킷이 손실되더라도 다른 스트림의 전송을 막지 않아, HTTP/2 over TCP에서 발생하는 Head-of-Line(HOL) 블로킹 문제를 해결한다.53
• 연결 마이그레이션: QUIC 연결은 IP 주소와 포트의 4-튜플이 아닌 연결 ID(Connection ID, CID)로 식별된다.52 이는 사용자가 Wi-Fi에서 셀룰러 네트워크로 전환하는 등 네트워크 환경이 변경되어도 연결이 끊어지거나 재설정될 필요 없이 원활하게 유지되도록 한다. 이는 모바일 사용자 경험에 있어 중대한 개선이다.54
• 향상된 보안: QUIC은 패킷 번호를 포함한 더 많은 전송 메타데이터를 암호화하여 네트워크 중간 장치가 수집할 수 있는 정보를 줄이고, 이를 통해 사용자 프라이버시를 향상시킨다.58

이러한 기능들은 QUIC이 단순한 성능 개선이 아니라, UDP 위에서 처음부터 다시 설계되었기에 가능한 근본적인 진보임을 보여준다. 보안이 더 이상 성능을 저해하는 오버헤드가 아니라, 0-RTT 및 연결 마이그레이션과 같은 핵심 성능 기능을 가능하게 하는 근본적인 요소로 작용하는 것이다.

초기 구글에 의해 개발된 gQUIC은 IETF에서 QUIC(RFC 9000)으로 표준화되었으며 53, 이는 HTTP/3(RFC 9114)의 기반이 되었다.60 IETF는 비신뢰성 데이터그램, 다중 경로, VPN 대체(MASQUE 워킹 그룹) 등 QUIC의 확장을 활발히 진행 중이다.58 그러나 QUIC의 강력한 암호화는 심층 패킷 검사(DPI)에 의존하는 기존의 네트워크 모니터링 및 보안 장비에 중대한 도전 과제를 제기한다.58

QUIC의 채택은 종단 간 암호화가 보편화되고 중간 장치의 가시성이 현저히 줄어드는 인터넷 패러다임으로의 전환을 의미한다. 이는 사용자 프라이버시를 강화하지만, 기업 보안팀이 네트워크 트래픽을 모니터링하는 방식을 근본적으로 재평가하도록 요구하며, 패킷 검사 기반의 보안 모델에서 엔드포인트 기반 분석 및 암호화된 트래픽 패턴 분석으로의 전환을 촉진한다.

본 섹션에서는 DTLS나 IPsec과 같은 표준 프로토콜이 너무 무겁거나 유연하지 않다고 판단되는 특정 시나리오를 다룬다. 특히 온라인 게임과 같이 극도의 성능 민감도를 요구하는 분야에서 개발된 맞춤형 보안 및 신뢰성 메커니즘에 초점을 맞추어, 보안, 성능, 복잡성 간의 트레이드오프를 분석한다.

빠른 속도의 멀티플레이어 게임과 같은 일부 극도로 지연 시간에 민감한 애플리케이션의 경우, 경량 보안 프로토콜의 오버헤드조차 허용되지 않을 수 있다.68 이러한 경우 개발자들은 완전한 프로토콜 스위트를 도입하는 대신, 자신들의 위협 모델에 맞춰 필요한 특정 보안 기능만을 직접 구현하는 방식을 선택할 수 있다. 예를 들어, 게임 개발자는 기밀성보다 치팅 방지(게임 상태 업데이트의 무결성 및 인증)를 더 중요하게 여겨 맞춤형 솔루션을 설계할 수 있다.

UDP의 비신뢰성을 보완하기 위해, 애플리케이션은 자체적으로 신뢰성 계층을 구축한다. 이는 “신뢰성 있는 UDP(Reliable UDP, RUDP)”라는 개념으로 알려져 있으며, 표준화된 프로토콜이 아닌 기술들의 집합이다.

• 시퀀스 번호: 모든 패킷에 순서 번호를 부여하여 패킷 손실을 탐지하고 도착 시 순서를 재조정한다.70
• 확인 응답 (ACK): 수신자는 수신한 패킷에 대해 ACK를 보내고, 송신자는 미확인 패킷을 버퍼에 유지하다가 타임아웃 시 재전송한다.70 고급 시스템에서는 ACK 비트필드를 사용하여 여러 패킷을 한 번에 확인 응답함으로써 대역폭을 절약한다.72
• 선택적 신뢰성: 모든 데이터를 동일하게 취급하지 않는다. 개발자들은 단일 UDP 소켓 위에 여러 가상 “채널”을 생성한다. 플레이어의 사망과 같은 중요한 이벤트는 신뢰성 있는 채널(ACK 및 재전송 포함)을 통해 전송되는 반면, 플레이어 위치 업데이트와 같이 빈번하고 비판적인 데이터는 비신뢰성 채널로 전송된다. 위치 업데이트 패킷이 손실되면, 곧 새로운 업데이트가 도착할 것이므로 무시된다.75

이러한 접근 방식은 개발자에게 메시지 단위로 신뢰성과 지연 시간 간의 트레이드오프를 정밀하게 제어할 수 있는 능력을 부여한다. 이는 단일 스트림에 대해 일관된 신뢰성을 제공하는 TCP와 같은 모놀리식 프로토콜에서는 불가능한 유연성이다.

통신을 보호하기 위해 애플리케이션은 자체적인 경량 핸드셰이크 및 암호화 방식을 구현할 수 있다. DTLS를 모방한 하이브리드 암호화 모델이 일반적인 패턴이다.25

1. 핸드셰이크: 클라이언트는 서버의 공개 RSA 키로 암호화된 AES 키를 포함한 ClientHello 메시지를 전송하여 핸드셰이크를 시작한다. 서버는 이를 복호화하고 응답하여 세션에 사용할 공유 AES 키를 설정한다.25
2. 세션 암호화: 핸드셰이크 이후의 모든 게임 트래픽은 설정된 빠르고 대칭적인 AES 키를 사용하여 암호화된다.25
3. 메시지 인증: 무결성을 보장하고 패킷 주입을 방지하기 위해, 각 패킷에는 HMAC(Hash-based Message Authentication Code)과 같은 메시지 인증 코드가 추가된다. HMAC은 공유 비밀 키와 해시 함수(예: SHA-256)를 사용하여 계산된다.77

이러한 “자체 제작 암호화” 접근 방식은 고도로 최적화될 수 있지만, 미묘한 구현상의 결함이 보안을 완전히 무력화시킬 수 있는 위험을 내포하고 있다. 따라서 이는 전문가에 의해서만 시도되어야 한다.

Riot Games와 같은 대규모 온라인 게임 회사는 네트워크 성능에 극도로 민감하며, 이들의 주된 보안 관심사는 기술적 치팅, 즉 스크립팅이나 봇을 이용한 패킷 조작 및 주입이다.80 이는 패킷 인증과 무결성에 대한 강력한 필요성을 시사한다. 또한, 다인용 게임은 상태 동기화 요구로 인해 단일 플레이어 게임보다 훨씬 많은 대역폭을 소모할 수 있다.80

이러한 환경에서는 고도로 맞춤화된 독점 RUDP 프로토콜을 사용할 가능성이 높다. 이 프로토콜은 다양한 유형의 게임 데이터를 처리하기 위한 다중 신뢰성 채널, 세션 키 설정을 위한 경량 맞춤형 핸드셰이크, 치팅 방지를 위한 패킷별 HMAC, 그리고 치트 개발자들의 프로토콜 리버스 엔지니어링을 막기 위한 암호화 기능을 포함할 것이다.68 여기서 주된 동인은 외부 도청으로부터의 기밀성 확보가 아니라, 경쟁의 공정성을 보장하기 위한 무결성과 인증이다. 이처럼 게임과 같은 특정 도메인의 보안은 일반적인 보안 목표와는 다른, 성능과 특정 위협 모델에 의해 정의된 “충분히 좋은(good enough)” 보안 스펙트럼 위에서 작동한다.

본 섹션에서는 앞서 논의된 프로토콜들을 직접 비교하여, 아키텍트와 개발자가 특정 요구사항에 맞는 최적의 보안 솔루션을 선택할 수 있도록 명확한 프레임워크를 제공한다.

• 연결 설정 지연 시간: IKE를 사용하는 IPsec은 일반적으로 가장 긴 연결 설정 지연 시간을 가지며, 여러 RTT(3-6 RTT)를 요구한다.82 DTLS는 이보다 빠르며, QUIC은 1-RTT 또는 0-RTT를 달성하여 가장 빠르다.54
• 처리 오버헤드 (CPU/메모리): IoT 환경 테스트에서 IPsec은 DTLS보다 전력 소모(CPU 사용률)가 낮을 수 있으나, DTLS의 메모리 사용률이 더 낮을 수 있다는 결과가 있다.85 다른 연구에서는 DTLS가 IPsec이나 TLS보다 처리 오버헤드가 가장 낮다고 보고한다.83 QUIC의 처리는 주로 사용자 공간에서 이루어져, 커널이나 하드웨어 가속을 사용하는 TCP/IPsec보다 고속 링크에서 느릴 수 있지만, 유연성이 높다.86
• 패킷당 오버헤드: IPsec 터널 모드는 상당한 크기의 헤더(새 IP 헤더 + ESP/AH 헤더, 약 40-60바이트 이상)를 추가한다.46 DTLS는 각 애플리케이션 데이터그램에 13바이트의 레코드 헤더를 추가한다. QUIC의 헤더는 가변적이지만 오버헤드를 추가한다.

성능 비교는 “어느 것이 가장 빠른가”라는 단순한 질문이 아니라, “특정 워크로드와 하드웨어 환경에서 어느 것이 가장 효율적인가”라는 맥락에서 이루어져야 한다. QUIC은 웹 애플리케이션의 연결 지연 시간 측면에서 명백한 승자이며, 하드웨어 지원이 있는 고속 네트워크에서는 IPsec이 높은 처리량을 보일 수 있다.

기능	DTLS	IPsec	QUIC
OSI 계층	전송 계층 (Layer 4)	네트워크 계층 (Layer 3)	전송 계층 (Layer 4)
전송 프로토콜	UDP	IP (TCP, UDP 등 상위 보호)	UDP
신뢰성 모델	애플리케이션에 위임 (핸드셰이크는 자체 신뢰성 확보)	투명 (상위 프로토콜 따름)	내장 (스트림 기반 신뢰성)
핸드셰이크 지연	중간 (2-4 RTT)	높음 (3-6 RTT)	낮음 (0-1 RTT)
HOL 블로킹	해당 없음 (데이터그램 기반)	해당 없음	해결 (스트림 멀티플렉싱)
연결 마이그레이션	미지원	미지원 (재연결 필요)	지원 (연결 ID 기반)
NAT 통과	기본적으로 통과	NAT-T 필요	내장 (UDP 기반)
구현 위치	사용자 공간 (라이브러리)	커널 공간 (OS)	사용자 공간 (라이브러리)
주요 사용 사례	VoIP, IoT, 특정 UDP 앱 보안	VPN, 사이트 간 터널링	HTTP/3, 현대 웹/API

• IPsec: 강력한 네트워크 수준 보안을 제공한다. ‘Encrypt-then-MAC’ 방식은 암호학적으로 더 견고한 것으로 평가된다.87 주된 약점은 IKE 프로토콜의 복잡성과 넓은 공격 표면이다.
• DTLS: TLS와 동등한 보안을 제공한다. TLS 상태 머신에 대한 공격에 취약할 수 있으며, 복잡성으로 인해 TLS보다 구현 오류가 발생할 가능성이 높다.33
• QUIC: 기본적으로 보안이 적용되며 최신 TLS 1.3 암호화를 사용한다. 더 많은 메타데이터를 암호화하여 프라이버시를 강화한다. 주된 보안 과제는 재전송 공격에 취약할 수 있는 0-RTT 메커니즘으로, 멱등성이 없는(non-idempotent) 작업에 사용되지 않도록 신중한 애플리케이션 설계가 요구된다.54

이러한 프로토콜들의 진화는 네트워크에 대한 투명성 감소와 프라이버시 강화라는 뚜렷한 경향을 보여준다. IPsec 전송 모드는 IP 헤더를 노출시키지만, QUIC은 전송 계층 메타데이터 대부분을 암호화한다. 이러한 불투명성의 증가는 사용자 프라이버시를 극적으로 향상시키지만, 심층 패킷 검사에 의존하는 전통적인 네트워크 관리 및 보안 모델을 무력화시킨다. 이는 향후 네트워크 보안이 네트워크 내부 검사보다 엔드포인트 보안 및 암호화된 트래픽 패턴 분석에 더 의존하게 될 것임을 시사한다.

• IPsec: 설정 및 관리가 가장 복잡하며, 깊은 네트워킹 지식, 커널 설정, 정교한 정책 관리를 필요로 한다.88
• DTLS: OpenSSL과 같은 라이브러리를 통해 애플리케이션 개발자가 통합하기 더 쉽다.34 그러나 개발자는 타임아웃 및 재전송과 같은 UDP 소켓 위의 DTLS API의 미묘한 차이를 직접 처리해야 하는 복잡성이 있다.33
• QUIC: 비교적 새로운 프로토콜이므로 라이브러리 및 도구 생태계가 성숙하는 단계에 있다. 구현 자체는 복잡하지만, 기존 라이브러리를 사용하는 애플리케이션 개발자에게는 라이브러리가 신뢰성 및 멀티플렉싱을 내부적으로 처리하므로 DTLS보다 간단할 수 있다.57

이러한 선택은 종종 조직 내에서 보안 책임이 어디에 있는지에 따라 결정된다. IPsec은 인프라팀의 도구이며, DTLS와 QUIC은 애플리케이션 개발팀의 도구이다.

이전의 모든 비교를 종합하여, 다음과 같은 명확한 의사결정 프레임워크를 제시한다.

• 사이트 간 또는 원격 접속 VPN: IPsec이 표준이며 최상의 선택이다. 투명하고 네트워크 전반에 걸친 보안을 제공하도록 설계되었다.
• 특정 클라이언트-서버 UDP 애플리케이션 보안 (예: IoT, VoIP): DTLS가 탁월한 선택이다. 네트워크 전반의 설정 오버헤드 없이 애플리케이션 수준에서 강력하고 표준화된 보안을 제공한다.
• 현대적인 고성능 웹/API 트래픽: QUIC (HTTP/3)이 미래의 표준이다. 우수한 성능과 현대적인 보안을 제공하여 새로운 웹 기반 서비스에 이상적이다.
• 극도로 낮은 지연 시간이 요구되는 실시간 게임: 표준 프로토콜의 성능이 벤치마킹 결과 불충분하다고 입증된 경우에 한해, 맞춤형 애플리케이션 계층 프로토콜이 정당화될 수 있다. 이는 고위험-고수익 옵션이다.

메트릭	DTLS	IPsec	QUIC	비고/맥락
연결 설정 지연 (RTTs)	중간 (2-4 RTTs)	높음 (3-6 RTTs)	낮음 (0-1 RTT)	QUIC은 재연결 시 0-RTT 가능
CPU 사용량 (정성적)	중간 (사용자 공간 암호화)	낮음-높음 (하드웨어 가속 유무)	중간-높음 (사용자 공간 처리)	하드웨어 가속 시 IPsec이 매우 효율적
메모리 사용량 (정성적)	낮음-중간	중간-높음 (커널 상태)	높음 (사용자 공간 스트림/버퍼)	QUIC은 복잡한 상태 관리로 메모리 요구량 높음
패킷당 대역폭 오버헤드	낮음 (약 13 바이트)	높음 (약 40-60 바이트)	중간 (가변적)	IPsec 터널 모드는 오버헤드가 가장 큼

본 섹션에서는 엔드포인트 프로토콜을 넘어, 프로토콜 수준의 보안만으로는 해결할 수 없는 대규모 UDP 기반 공격을 방어하는 데 있어 네트워크 인프라와 제3자 서비스의 중요한 역할을 논의한다.

기본적인 방어는 네트워크 경계에서 시작된다. 방화벽은 사용하지 않는 모든 UDP 포트를 차단하도록 설정해야 한다.9 UDP를 반드시 사용해야 하는 서비스의 경우, 단일 소스가 서비스를 압도하는 것을 방지하기 위해 속도 제한(rate-limiting)을 적용할 수 있다.9 침입 탐지 시스템(IDS)은 사용되지 않는 포트로의 UDP 트래픽 급증이나 ICMP “Destination Unreachable” 응답률의 급격한 증가와 같은 비정상적인 트래픽 패턴을 모니터링하여 UDP 플러딩 공격의 징후를 탐지할 수 있다.9

네트워크 링크를 포화시키는 대규모 볼류메트릭 DDoS 공격에 대해서는 프로토콜 수준의 보안이 무력하다.12 이러한 공격을 완화하기 위해서는 막대한 네트워크 용량과 전문화된 스크러빙 센터가 필요하다.

• Cloudflare: 거대한 글로벌 애니캐스트(Anycast) 네트워크(388 Tbps 용량)를 활용하여 공격 트래픽을 소스에 가까운 엣지에서 흡수하고 완화한다.95

  Spectrum은 게임 서버와 같은 일반 TCP/UDP 애플리케이션을 보호하는 제품으로, 오리진 서버를 숨기고 DDoS 보호를 적용하는 Layer 4 리버스 프록시 역할을 한다.95

• AWS Shield: 관리형 DDoS 보호 서비스이다. Shield Standard는 무료로 제공되며 SYN 플러드, UDP 반사 공격과 같은 일반적인 L3/4 공격을 방어한다.15 Shield Advanced는 향상된 보호 기능과 24/7 DDoS 대응팀(DRT) 접근, L7 공격 방어 등을 제공한다.99

• Google Cloud Armor: 구글 네트워크 엣지에서 구글 클라우드 부하 분산기 뒤의 애플리케이션을 보호한다.102 UDP 트래픽 필터링을 지원하며, 대규모 공격이 리소스를 소모하기 전에 차단하는 네트워크 엣지 보안 정책을 제공한다.102

이러한 서비스의 가치는 공격자가 동원할 수 있는 것보다 훨씬 큰 규모의 대역폭을 보유하고 있다는 점에서 비롯된다. 현대의 DDoS 방어는 사실상 클라우드 엣지로 아웃소싱되었으며, 이는 대규모 공격을 처리할 수 있는 유일한 방법이다.

BCP 38(RFC 2827)은 ISP가 자신의 고객 네트워크에서 나가는 트래픽 중, 해당 고객에게 할당되지 않은 위조된 출발지 IP 주소를 가진 패킷을 필터링(인그레스 필터링)하도록 권고하는 모범 사례이다.105 이 조치가 전 세계적으로 시행된다면 IP 스푸핑을 원천적으로 차단하여 반사 및 증폭 공격을 사실상 불가능하게 만들 수 있다.13

그러나 20년 이상 알려진 해결책임에도 불구하고 BCP 38의 채택률은 여전히 저조하다.108 주된 이유는 인센티브의 불일치 때문이다. 이를 구현하는 ISP는 운영 비용과 복잡성을 부담해야 하는 반면, 그 혜택(DDoS 공격 감소)은 인터넷 전체가 누리게 된다.108 멀티호밍과 같은 복잡한 고객 네트워크 구성에 대한 기술적 어려움도 존재한다.105

UDP 반사 공격은 일종의 “공유지의 비극” 문제이다. BCP 38은 기술적 해결책이지만, 경제적 및 운영적 요인으로 인해 보편적으로 채택되지 못하는 현실은 기술적 해결책만으로는 인터넷 보안 문제를 해결하기에 충분하지 않음을 보여준다.

본 마지막 섹션에서는 새로운 트렌드를 조망하고, 견고하고 다층적인 UDP 보안 태세를 구축하기 위한 통합된 실천 권고안을 제시한다.

양자 컴퓨팅의 발전은 현재 프로토콜 핸드셰이크에 사용되는 공개 키 암호(RSA, ECC 등)를 무력화할 위협이 되고 있다.110 특히 “지금 수집하고, 나중에 해독하는(harvest now, decrypt later)” 위협은 심각하다. 공격자들은 현재의 암호화된 트래픽을 저장해 두었다가 미래의 양자 컴퓨터로 해독할 수 있다.110

이에 대응하여 IETF는 TLS, DTLS, QUIC에 양자내성암호(PQC)를 통합하는 작업을 진행 중이다. 초기 접근 방식은 전통적인 알고리즘(예: X25519)과 PQC 알고리즘(예: ML-KEM)을 결합하는 “하이브리드” 키 교환이다. 이는 둘 중 하나의 알고리즘이라도 안전하게 유지되는 한 보안을 보장한다.110

그러나 PQC 알고리즘은 공개 키와 서명 크기가 훨씬 커서 핸드셰이크 패킷의 크기를 증가시키는 문제를 야기한다.111 이는 IP 단편화를 피하고 안정적인 전달을 보장해야 하는 UDP 기반 프로토콜인 DTLS와 QUIC에 특히 큰 도전 과제이다.113 PQC로의 전환은 “핸드셰이크 비대화(handshake bloat)”라는 새로운 성능 문제를 야기할 것이며, 이는 인증서 압축과 같은 새로운 최적화 기술의 필요성을 부각시킨다.37

IETF의 TSVWG(Transport and Services Working Group)는 UDP를 개선하기 위한 방안을 모색하고 있다. 여기에는 핵심 프로토콜 변경 없이 UDP 데이터그램 내에 새로운 전송 계층 기능을 추가할 수 있도록 하는 “UDP 옵션” 표준화 초안이 포함된다.114 다른 연구들은 오프-패스(off-path) 공격을 어렵게 만들기 위한 포트 무작위화 개선 116 및 새로운 전송 서비스에 대한 가이드라인 제공에 초점을 맞추고 있다.117

이러한 움직임은 UDP가 단순한 데이터그램 서비스를 넘어, 다양한 수준의 신뢰성과 보안을 갖춘 전송 서비스들을 구축할 수 있는 기초 “기판(substrate)”으로 진화하고 있음을 시사한다. 미래의 UDP는 단일 프로토콜이 아닌, 여러 계층으로 이루어진 생태계가 될 것이다. 최하위에는 순수 UDP가, 그 위에는 “UDP 옵션”이나 경량 프레임워크가, 그리고 최상위에는 QUIC과 같은 완전한 전송 프로토콜이 위치하게 될 것이다.

본 보고서의 전체 분석을 바탕으로, 보안 아키텍트를 위한 실천 가능한 권고안을 다음과 같이 요약한다.

• 프로토콜 개발 (보안 SDLC): 설계 단계부터 보안을 통합하라. 위협 모델링을 통해 UDP 애플리케이션의 특정 위험을 식별하고, 자체 암호화 구현 대신 검증된 암호화 라이브러리를 사용하며, 보안 코딩 표준을 준수하라.119
• 프로토콜 선택: 6.4절의 의사결정 프레임워크를 활용하라. VPN에는 IPsec, 특정 UDP 서비스 보안에는 DTLS, 현대 웹 트래픽에는 QUIC을 선택하는 등, 목적에 맞는 올바른 도구를 사용하라. 절대적으로 필요한 경우가 아니면 맞춤형 구현보다 표준화된 프로토콜을 우선시하라.
• 구성 강화:
  • DTLS/IPsec: DTLS 1.0과 같은 구식 프로토콜 버전과 취약한 암호화 스위트를 비활성화하라. 다중 인증(MFA), 인증서 기반 인증을 사용하고, 완전 순방향 비밀성을 활성화하라.37
  • 모든 서비스: 최소 권한 원칙을 준수하고, 불필요한 서비스와 포트를 비활성화하며, 강력한 암호 정책을 시행하고 고유한 자격 증명을 사용하라.38
• 인프라 방어: 프로토콜 수준의 보안만으로는 충분하지 않다고 가정하라. 대규모 DDoS 완화 서비스(예: Cloudflare, AWS Shield, Google Cloud Armor) 뒤에 서비스를 배포하고, 네트워크 경계에서 엄격한 방화벽 규칙과 속도 제한을 구현하라.
• 옹호 및 계획: 거래하는 ISP에 BCP 38 구현을 촉구하라. DDoS 공격에 특화된 사고 대응 계획을 수립하고, PQC 및 새로운 전송 프로토콜의 발전을 주시하며 미래를 대비하라.

1. [네트워크] TCP/UDP 특징 - 코딩 버릇 여든까지 간다 - 티스토리, accessed July 28, 2025, https://yelkim0210.tistory.com/139
2. TCP와 UDP의 특징과 차이점, accessed July 28, 2025, https://feccle.tistory.com/50
3. TCP UDP 차이: 두 프로토콜 비교 - NordVPN, accessed July 28, 2025, https://nordvpn.com/ko/blog/tcp-udp-comparison/
4. User Datagram Protocol - Wikipedia, accessed July 28, 2025, https://en.wikipedia.org/wiki/User_Datagram_Protocol
5. User Datagram Protocol (UDP) - GeeksforGeeks, accessed July 28, 2025, https://www.geeksforgeeks.org/computer-networks/user-datagram-protocol-udp/
6. A guide to UDP (User Datagram Protocol) - Comparitech, accessed July 28, 2025, https://www.comparitech.com/net-admin/guide-udp-user-datagram-protocol/

7. What is UDP

   From Header Structure to Packets Used in DDoS …, accessed July 28, 2025, https://www.imperva.com/learn/ddos/udp-user-datagram-protocol/

8. www.cloudflare.com, accessed July 28, 2025, https://www.cloudflare.com/learning/ddos/glossary/ip-spoofing/#:~:text=IP%20Spoofing%20is%20analogous%20to,return%20address%20is%20easily%20changed.
9. UDP Flood DDoS 공격이란 무엇입니까? - 씨디네트웍스 - CDNetworks, accessed July 28, 2025, https://www.cdnetworks.com/ko/glossary/udp-flood-ddos-attack/
10. UDP 플러드 DDoS 공격이란 무엇일까요? - Akamai, accessed July 28, 2025, https://www.akamai.com/ko/glossary/what-is-udp-flood-ddos-attack
11. iptables을 이용한 UDP Flood 방어 - Plummmm - 티스토리, accessed July 28, 2025, https://plummmm.tistory.com/426
12. UDP 폭주 DDoS 공격 - Cloudflare, accessed July 28, 2025, https://www.cloudflare.com/ko-kr/learning/ddos/udp-flood-ddos-attack/
13. DNS amplification DDoS attack - Cloudflare, accessed July 28, 2025, https://www.cloudflare.com/learning/ddos/dns-amplification-ddos-attack/
14. Memcached Server Attacks – Cyber - University of Hawaii West Oahu, accessed July 28, 2025, https://westoahu.hawaii.edu/cyber/vulnerability-research/memcached-server-attacks/
15. UDP reflection attacks - AWS Best Practices for DDoS Resiliency, accessed July 28, 2025, https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/udp-reflection-attacks.html
16. Detecting DNS Amplification Attacks - Computer Science, Columbia University, accessed July 28, 2025, http://www.cs.columbia.edu/~dgen/papers/conferencees/Camera_Ready_34.pdf
17. An Overview of DNS Amplification Attack Defense via Flow-Based Analysis and SDN, accessed July 28, 2025, https://www.researchgate.net/publication/306082875_An_Overview_of_DNS_Amplification_Attack_Defense_via_Flow-Based_Analysis_and_SDN
18. (PDF) Detecting DNS Amplification Attacks - ResearchGate, accessed July 28, 2025, https://www.researchgate.net/publication/220816528_Detecting_DNS_Amplification_Attacks
19. Memcached Exploit Amplifies DRDoS Attacks - NHS England Digital, accessed July 28, 2025, https://digital.nhs.uk/cyber-alerts/2018/cc-2116
20. CVE-2018-1000115 - NVD, accessed July 28, 2025, https://nvd.nist.gov/vuln/detail/CVE-2018-1000115
21. Memcached: An Experimental Study of DDoS Attacks for the Wellbeing of IoT Applications, accessed July 28, 2025, https://pmc.ncbi.nlm.nih.gov/articles/PMC8659833/
22. 30년된 레디어스 프로토콜에서 30년 된 설계 오류 발견돼 - 보안뉴스, accessed July 28, 2025, https://m.boannews.com/html/detail.html?idx=131268
23. 데이터그램 전송 계층 보안 DTLS 개념 이해 - 유아마루, accessed July 28, 2025, https://urmaru.com/5
24. DTLS - 나무위키, accessed July 28, 2025, https://namu.wiki/w/DTLS

25. UDP Socket manager for go server-side

    by Sajjad Rad

    Medium, accessed July 28, 2025, https://theredrad.medium.com/udp-socket-manager-for-go-server-side-9b1382005fe1

26. DTLSv1_listen - OpenSSL Documentation, accessed July 28, 2025, https://docs.openssl.org/3.1/man3/DTLSv1_listen/
27. SRTP using DTLS Protocol - AudioCodes, accessed July 28, 2025, https://techdocs.audiocodes.com/session-border-controller-sbc/mediant-800-sbc/user-manual/version-760/Content/UM/SRTP-using-DTLS-Protocol.htm
28. DTLS-SRTP Overview - Oracle Help Center, accessed July 28, 2025, https://docs.oracle.com/en/industries/communications/session-border-controller/9.2.0/configuration/dtls-srtp-overview.html
29. RFC 5764 - Datagram Transport Layer Security (DTLS) Extension to Establish Keys for the Secure Real-time Transport Protocol (SRTP) - Datatracker - IETF, accessed July 28, 2025, https://datatracker.ietf.org/doc/html/rfc5764
30. Understanding DTLS Usage in VoIP Communications - Gremwell, accessed July 28, 2025, https://www.gremwell.com/blog/dtls-srtp
31. RFC 7879 - DTLS-SRTP Handling in SIP Back-to-Back User Agents - Datatracker, accessed July 28, 2025, https://datatracker.ietf.org/doc/html/rfc7879
32. DTLS-SRTP - Oracle Help Center, accessed July 28, 2025, https://docs.oracle.com/en/industries/communications/session-border-controller/9.2.0/configuration/dtls-srtp.html
33. Analysis of DTLS Implementations Using Protocol State Fuzzing - USENIX, accessed July 28, 2025, https://www.usenix.org/system/files/sec20-fiterau-brostean.pdf
34. simple dtls server client example with openssl custom-bio over udp - GitHub, accessed July 28, 2025, https://github.com/stepheny/openssl-dtls-custom-bio
35. Examples for DTLS via SCTP and UDP using OpenSSL - GitHub, accessed July 28, 2025, https://github.com/nplab/DTLS-Examples
36. DTLS Implementation Notes - Net-SNMP Wiki, accessed July 28, 2025, http://www.net-snmp.org/wiki/index.php/DTLS_Implementation_Notes
37. RFC 9325: Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) - » RFC Editor, accessed July 28, 2025, https://www.rfc-editor.org/rfc/rfc9325.html
38. Avoid These 7 Mistakes When Implementing Secure Network Protocols - DPS Telecom, accessed July 28, 2025, https://www.dpstele.com/blog/common-secure-network-mistakes.php
39. DTLS Security for COAP Protocol in IoT - S-Logix, accessed July 28, 2025, https://slogix.in/internet-of-things/dtls-security-for-coap-protocol/
40. DTLS for IoT: Best Practices and Challenges - Number Analytics, accessed July 28, 2025, https://www.numberanalytics.com/blog/dtls-for-iot-best-practices-and-challenges

41. IPsec 기본 사항

    Junos OS - Juniper Networks, accessed July 28, 2025, https://www.juniper.net/documentation/kr/ko/software/junos/vpn-ipsec/topics/topic-map/security-ipsec-basics.html

42. IPSec의 정의 및 VPN에 사용되는 원리, accessed July 28, 2025, https://nordvpn.com/ko/blog/ipsec-vpn-explained/

43. IPsec이란?

    VPN 작동 방식 - Cloudflare, accessed July 28, 2025, https://www.cloudflare.com/ko-kr/learning/network-layer/what-is-ipsec/

44. [네트워크/보안] IPSec 개념과 원리, 특징 1 - REAKWON - 티스토리, accessed July 28, 2025, https://reakwon.tistory.com/108
45. [CS 지식17.] IPsec vs SSL/TLS - Somaz의 IT 공부 일지 - 티스토리, accessed July 28, 2025, https://somaz.tistory.com/344
46. IPsec Transport/Tunnel 모드 - 불이 꺼지지 않는 연구소, accessed July 28, 2025, https://pyromaniac.me/entry/IPsec-TransportTunnel-%EB%AA%A8%EB%93%9C
47. RFC 3947 - Negotiation of NAT-Traversal in the IKE - Datatracker - IETF, accessed July 28, 2025, https://datatracker.ietf.org/doc/html/rfc3947
48. IPsec and NAT Traversal (System Administration Guide: IP Services), accessed July 28, 2025, https://docs.oracle.com/cd/E19120-01/open.solaris/819-3000/ipsec-ov-24/index.html
49. NAT Traversal - strongSwan Documentation, accessed July 28, 2025, https://docs.strongswan.org/docs/latest/features/natTraversal.html
50. draft-ietf-ipsec-nat-t-ike-08 - Negotiation of NAT-Traversal in the IKE - IETF Datatracker, accessed July 28, 2025, https://datatracker.ietf.org/doc/draft-ietf-ipsec-nat-t-ike/08/
51. NAT-T clarification - Cisco Learning Network, accessed July 28, 2025, https://learningnetwork.cisco.com/s/question/0D53i00000Kstbg/natt-clarification
52. IETF QUIC v1 Design, accessed July 28, 2025, https://www.cse.wustl.edu/~jain/cse570-21/ftp/quic/index.html
53. QUIC - Wikipedia, accessed July 28, 2025, https://en.wikipedia.org/wiki/QUIC
54. QUIC: The Secure Communication Protocol Shaping the Internet’s Future - Zscaler, accessed July 28, 2025, https://www.zscaler.com/blogs/product-insights/quic-secure-communication-protocol-shaping-future-of-internet
55. The Road to QUIC - The Cloudflare Blog, accessed July 28, 2025, https://blog.cloudflare.com/the-road-to-quic/
56. QUIC and the future of Internet transport - Compira labs, accessed July 28, 2025, https://www.compiralabs.com/post/quic-and-the-future-of-internet-transport
57. What is the difference between DTLS and QUIC protocol, as they are both TLS over UDP?, accessed July 28, 2025, https://www.quora.com/What-is-the-difference-between-DTLS-and-QUIC-protocol-as-they-are-both-TLS-over-UDP
58. QUIC Will Eat the Internet - F5 Networks, accessed July 28, 2025, https://www.f5.com/company/blog/quic-will-eat-the-internet
59. Comparing Quic and TLS for Enterprise Security - Lightyear.ai, accessed July 28, 2025, https://lightyear.ai/tips/quic-versus-tls
60. RFC 9114 - HTTP/3 - IETF Datatracker, accessed July 28, 2025, https://datatracker.ietf.org/doc/html/rfc9114
61. RFC 9001: Using TLS to Secure QUIC, accessed July 28, 2025, https://quicwg.org/base-drafts/rfc9001.html
62. draft-ietf-quic-tls-13 - Datatracker, accessed July 28, 2025, https://datatracker.ietf.org/doc/html/draft-ietf-quic-tls-13
63. The Maturing of QUIC - Fastly, accessed July 28, 2025, https://www.fastly.com/blog/maturing-of-quic
64. What is QUIC? Understand The Protocol - Check Point Software, accessed July 28, 2025, https://www.checkpoint.com/cyber-hub/network-security/what-is-quic/
65. [2408.01791] Implementing NAT Hole Punching with QUIC - arXiv, accessed July 28, 2025, https://arxiv.org/abs/2408.01791
66. QUIC Working Group, accessed July 28, 2025, https://quicwg.org/
67. QUIC’s acceptance and it’s security approach : r/networking - Reddit, accessed July 28, 2025, https://www.reddit.com/r/networking/comments/1jdhnuh/quics_acceptance_and_its_security_approach/
68. Should I encrypt my multiplayer network traffic? - Game Development Stack Exchange, accessed July 28, 2025, https://gamedev.stackexchange.com/questions/115615/should-i-encrypt-my-multiplayer-network-traffic
69. UDP for games – security (encryption and DDoS protection) - IT Hare on Soft.ware, accessed July 28, 2025, http://ithare.com/udp-for-games-security-encryption-and-ddos-protection/
70. Using Tcp and Udp in a multiplayer game? : r/gamedev - Reddit, accessed July 28, 2025, https://www.reddit.com/r/gamedev/comments/m5sbxp/using_tcp_and_udp_in_a_multiplayer_game/
71. UDP Reliable Delivery Algorithms - io7m.com, accessed July 28, 2025, https://www.io7m.com/documents/udp-reliable/
72. Reliable Ordered Messages - Gaffer On Games, accessed July 28, 2025, https://gafferongames.com/post/reliable_ordered_messages/

73. Assignment 1 Reliable UDP

    Adv. Networking and Distributed Systems, accessed July 28, 2025, https://gwadvnet20.github.io/assignments/reliable-udp

74. fracturestudios/radon: Reliable, one-time delivery UDP for C++ - GitHub, accessed July 28, 2025, https://github.com/fracturestudios/radon
75. how does UDP works? example in online games [closed] - Stack Overflow, accessed July 28, 2025, https://stackoverflow.com/questions/16852025/how-does-udp-works-example-in-online-games

76. Unity Realtime Multiplayer, Part 3: Reliable UDP Protocol

    by MY.GAMES - Medium, accessed July 28, 2025, https://medium.com/my-games-company/unity-realtime-multiplayer-part-3-reliable-udp-protocol-94fbffe8c72c

77. What is HMAC(Hash based Message Authentication Code)? - GeeksforGeeks, accessed July 28, 2025, https://www.geeksforgeeks.org/computer-networks/what-is-hmachash-based-message-authentication-code/

78. Example C Program: Creating an HMAC - Win32 apps

    Microsoft Learn, accessed July 28, 2025, https://learn.microsoft.com/en-us/windows/win32/seccrypto/example-c-program–creating-an-hmac

79. Designing a secure UDP-based communication protocol - Cryptography Stack Exchange, accessed July 28, 2025, https://crypto.stackexchange.com/questions/85696/designing-a-secure-udp-based-communication-protocol
80. Minions, Servers, and Progression – The Tech Behind Swarm - Riot Games, accessed July 28, 2025, https://www.riotgames.com/en/news/the-tech-behind-swarm
81. Riot’s Approach to Anti-Cheat, accessed July 28, 2025, https://technology.riotgames.com/news/riots-approach-anti-cheat

82. COMPARISON TABLE Overhead IPSec/TCP TLS/TCP DTLS/SCTP TCP SCTP

    Download Table - ResearchGate, accessed July 28, 2025, https://www.researchgate.net/figure/COMPARISON-TABLE-Overhead-IPSec-TCP-TLS-TCP-DTLS-SCTP-TCP-SCTP_tbl5_311534480

83. (PDF) Securing Diameter: Comparing TLS, DTLS, and IPSec - ResearchGate, accessed July 28, 2025, https://www.researchgate.net/publication/311534480_Securing_Diameter_Comparing_TLS_DTLS_and_IPSec
84. Performance and Security Evaluation of TLS, DTLS and QUIC Security Protocols - Webthesis, accessed July 28, 2025, https://webthesis.biblio.polito.it/secure/25561/1/tesi.pdf
85. Performance analysis of end-to-end DTLS and IPsec-based communication in IoT environments - DiVA portal, accessed July 28, 2025, http://www.diva-portal.org/smash/get/diva2:1157047/FULLTEXT02
86. QUIC is not Quick Enough over Fast Internet : r/programming - Reddit, accessed July 28, 2025, https://www.reddit.com/r/programming/comments/1g7vv66/quic_is_not_quick_enough_over_fast_internet/
87. What’s the advantage of IPSec over TLS/DTLS? - Network Engineering Stack Exchange, accessed July 28, 2025, https://networkengineering.stackexchange.com/questions/75722/whats-the-advantage-of-ipsec-over-tls-dtls
88. SSL VPN vs IPsec: A Comparison - NinjaOne, accessed July 28, 2025, https://www.ninjaone.com/blog/ssl-vpn-vs-ipsec/
89. ipsec.conf: IPsec configuration and connections - Linux Manuals (5) - SysTutorials, accessed July 28, 2025, https://www.systutorials.com/docs/linux/man/5-ipsec.conf/
90. Linux/CentOS IPsec Configuration, accessed July 28, 2025, https://docs.logrhythm.com/lrsiem/docs/linux-centos-ipsec-configuration
91. Comparing SSL/TLS and IPsec - Choosing the Right Protocol for Your Network Needs, accessed July 28, 2025, https://medium.com/@RocketMeUpCybersecurity/comparing-ssl-tls-and-ipsec-choosing-the-right-protocol-for-your-network-needs-423b9f4aa218
92. Datagram Transport Layer Security - Robin Seggelmann, accessed July 28, 2025, https://www.robin-seggelmann.de/papers/dtls.pdf

93. 공격 탐지 및 방지를 위한 스크린 옵션

    Junos OS

    주니퍼 네트웍스 - Juniper Networks, accessed July 28, 2025, https://www.juniper.net/documentation/kr/ko/software/junos/denial-of-service/topics/topic-map/security-introduction-to-adp.html

94. [시장동향] 대규모 디도스 공격, 알아야 대비한다 - 컴퓨터월드, accessed July 28, 2025, https://www.comworld.co.kr/news/articleView.html?idxno=49427
95. DDoS Protection & Mitigation Solutions - Cloudflare, accessed July 28, 2025, https://www.cloudflare.com/ddos/
96. Cloudflare Security Architecture, accessed July 28, 2025, https://developers.cloudflare.com/reference-architecture/architectures/security/

97. Spectrum

    DDoS protection for TCP & UDP applications - Cloudflare, accessed July 28, 2025, https://www.cloudflare.com/application-services/products/cloudflare-spectrum/

98. Spectrum for UDP: DDoS protection and firewalling for unreliable protocols, accessed July 28, 2025, https://blog.cloudflare.com/spectrum-for-udp-ddos-protection-and-firewalling-for-unreliable-protocols/
99. Shield Advanced: Advanced DDoS Mitigation - AWS Security Maturity Model, accessed July 28, 2025, https://v1.maturitymodel.security.aws.dev/en/3.-efficient/shield-advanced/
100. Advanced DDoS Mitigation (Layer 7) - AWS Shield, accessed July 28, 2025, https://maturitymodel.security.aws.dev/en/3.-efficient/shield-advanced/
101. Mitigation techniques - AWS Best Practices for DDoS Resiliency, accessed July 28, 2025, https://docs.aws.amazon.com/whitepapers/latest/aws-best-practices-ddos-resiliency/mitigation-techniques.html

102. Security policy overview

     Google Cloud Armor, accessed July 28, 2025, https://cloud.google.com/armor/docs/security-policy-overview

103. Fortress in the Cloud: Leveraging Google Cloud Armor to Protect Your Applications, accessed July 28, 2025, https://www.anantacloud.com/post/fortress-in-the-cloud-leveraging-google-cloud-armor-to-protect-your-applications

104. Cloud Armor for NLB/VM with User Defined Rules

     Google Codelabs, accessed July 28, 2025, https://codelabs.developers.google.com/codelabs/ca4nlb-phase2

105. draft-savola-bcp38-multihoming-update-03 - Ingress Filtering for Multihomed Networks, accessed July 28, 2025, https://datatracker.ietf.org/doc/draft-savola-bcp38-multihoming-update/03/
106. BCP 38 - Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing - Institute for Security and Technology, accessed July 28, 2025, https://securityandtechnology.org/wp-content/uploads/2020/07/bcp38.pdf
107. Why is Source Address Validation still a problem? - APNIC Blog, accessed July 28, 2025, https://blog.apnic.net/2023/05/03/why-is-source-address-validation-still-a-problem/
108. SAVing the Internet: Explaining the Adoption of Source Address Validation by Internet Service Providers - WEIS 2017, accessed July 28, 2025, https://weis2017.econinfosec.org/wp-content/uploads/sites/8/2020/06/weis20-final31.pdf
109. ISP Column - June 2019 - Geoff Huston, accessed July 28, 2025, https://www.potaroo.net/ispcol/2019-06/dedr.html
110. draft-kwiatkowski-pquip-pqc-migration-00 - Guidance for migration to Post-Quantum Cryptography - Datatracker, accessed July 28, 2025, https://datatracker.ietf.org/doc/draft-kwiatkowski-pquip-pqc-migration/
111. Post-Quantum Cryptography Recommendations for Internet Applications - IETF, accessed July 28, 2025, https://www.ietf.org/archive/id/draft-reddy-uta-pqc-app-03.html
112. Post-Quantum Cryptography Recommendations for Applications - IETF, accessed July 28, 2025, https://www.ietf.org/archive/id/draft-reddy-uta-pqc-app-04.html
113. Using TLS to Secure QUIC, accessed July 28, 2025, https://greenbytes.de/tech/webdav/draft-ietf-quic-tls-18.html
114. draft-ietf-tsvwg-udp-options-28, accessed July 28, 2025, https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-28
115. draft-ietf-tsvwg-udp-options-45 - Transport Options for UDP - Datatracker, accessed July 28, 2025, https://datatracker.ietf.org/doc/draft-ietf-tsvwg-udp-options/45/
116. draft-ietf-tsvwg-port-randomization-01 - Datatracker, accessed July 28, 2025, https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-port-randomization-01
117. RFC 8095: Services Provided by IETF Transport Protocols and Congestion Control Mechanisms, accessed July 28, 2025, https://www.rfc-editor.org/rfc/rfc8095.html
118. Transport and Services Working Group (tsvwg) - Datatracker - IETF, accessed July 28, 2025, https://datatracker.ietf.org/group/tsvwg/
119. What Is SDLC Security? - Palo Alto Networks, accessed July 28, 2025, https://www.paloaltonetworks.com/cyberpedia/what-is-secure-software-development-lifecycle
120. nys-s13-001-secure-system-development-life-cycle.pdf - Office of Information Technology Services, accessed July 28, 2025, https://its.ny.gov/system/files/documents/2024/05/nys-s13-001-secure-system-development-life-cycle.pdf
121. The Secure Software Development Framework (SSDF) - Wiz, accessed July 28, 2025, https://www.wiz.io/academy/secure-software-development-framework-ssdf
122. VPN Security Audit Checklist for Network Admins - 10 Steps to Secure Your VPN, accessed July 28, 2025, https://blog.vpntracker.com/vpn-security-audit-checklist-for-network-admins-10-steps-to-secure-your-vpn/
123. Selecting and Hardening Remote Access VPN Solutions, accessed July 28, 2025, https://media.defense.gov/2021/Sep/28/2002863184/-1/-1/0/csi_selecting-hardening-remote-access-vpns-20210928.pdf
124. Cisco NX-OS Software Hardening Guide, accessed July 28, 2025, https://sec.cloudapps.cisco.com/security/center/resources/securing_nx_os.html
125. Systems Hardening Best Practices to Reduce Risk [Checklist] - NinjaOne, accessed July 28, 2025, https://www.ninjaone.com/blog/complete-guide-to-systems-hardening/