VPN(Virtual Private Network, 가상사설망)

대문 / 프로그래밍, 네트웍 / VPN(Virtual Private Network, 가상사설망)

VPN(Virtual Private Network, 가상사설망)

  • 작성자
    조재혁(Mminzkn@minzkn.com)

  • 고친과정
    2016년 12월 9일 : 처음씀

    2018년 2월 8일 : 추가 정리

Contents

1. VPN(Virtual Private Network, 가상사설망)
1.1. 개요
1.1.1. VPN의 목적
1.1.2. VPN 주요 용어
1.1.3. VPN의 요소
1.1.4. VPN의 종류
1.2. IPSec VPN
1.2.1. IPSec VPN 관련 주요 표준
1.2.2. 구성요소
1.2.3. ISAKMP (~= IKEv1, Internet Security Association and Key Management Protocol)
1.2.3.1. ISAKMP의 역할
1.2.3.2. ISAKMP의 기본 충족 요건
1.2.3.3. 키 교환(Key exchange) 요소
1.2.3.4. 키교환 과정
1.2.3.5. 키교환 모드
1.2.3.6. IKEv1 Main mode
1.2.3.7. IKEv1 Aggressive mode
1.2.3.8. IKEv1 Quick mode
1.2.3.9. [https]SA (Security Association, 보안 관련 집합정보)[](https://en.wikipedia.org/wiki/Security_association) 요소
1.2.3.10. ISAKMP Header Format with payload
1.2.3.11. ISAKMP Header Format
1.2.3.12. Generic Payload Header
1.2.3.13. Data Attributes
1.2.3.14. Security Association Payload
1.2.4. IKEv2 ([https]RFC7296 - Internet Key Exchange Protocol Version 2[](https://www.rfc-editor.org/rfc/rfc7296))
1.2.4.1. IKE Header Format
1.2.4.2. Generic Payload Header
1.2.4.3. Generic Attributes Format
1.2.4.4. Security Association Payload
1.2.4.5. Key Exchange Payload
1.2.4.6. Identification Payloads
1.2.4.7. Certificate Payload
1.2.4.8. Certificate Request Payload
1.2.4.9. Authentication Payload
1.2.4.10. Nonce Payload
1.2.4.11. Notify Payload
1.2.4.12. Delete Payload
1.2.4.13. Vendor ID Payload
1.2.4.14. Traffic Selector Payload
1.2.4.15. Encrypted Payload
1.2.4.16. Configuration Payload
1.2.4.17. Extensible Authentication Protocol (EAP) Payload
1.2.5. ESP ([https]RFC4303 - IP Encapsulating Security Payload[](https://www.rfc-editor.org/rfc/rfc4303))
1.2.5.1. ESP Header Format
1.2.5.2. [https]RFC4305 - Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)[](https://tools.ietf.org/html/rfc4305)
1.2.6. AH ([https]RFC4302 - IP Authentication Header[](https://tools.ietf.org/html/rfc4302))
1.2.7. IPCOMP ([https]RFC3173 - IP Payload Compression Protocol[](https://tools.ietf.org/html/rfc3173))
1.3. 문제해결(TroubleShooting)
1.3.1. 프로토콜 문제
1.3.2. 성능 문제
1.3.3. 보안 문제
1.4. 참고자료
1.4.1. Linux Kernel 에서의 Transform(IPSec VPN, xfrm) 흐름도 정리
1.4.1.1. Linux Kernel v3.x 기준 Transform(IPSec VPN, xfrm) packet 흐름의 요약 정리
1.4.1.2. Linux Kernel v3.x 기준 Transform(IPSec VPN, xfrm) packet 흐름에서 암호화(Encrypt) 부분 요약 정리
1.4.1.3. Linux Kernel v3.x 기준 Transform(IPSec VPN, xfrm) packet 흐름에서 복호화(Decrypt) 부분 요약 정리
1.4.1.4. Linux Kernel v3.x 기준 Transform(IPSec VPN, xfrm) packet 흐름도 상세 정리
1.4.1.5. Linux Kernel v3.x 기준 xfrm_lookup 함수 정리
1.4.1.6. Linux Kernel v5.x 에서의 XDP 및 xfrm(IPSec) 흐름 요약
1.4.2. 용어정의
1.4.3. 관련 표준안
1.4.4. 표준안 관련 도움글
1.4.5. 내부 관련 글
1.4.6. 관련 글
1.4.7. 관련 참고할만한 자체 공개프로젝트
1.4.8. 관련 주요 공개프로젝트
1.4.9. 관련 서적

1.1. 개요

VPN(Virtual Private Network)은 각 Private Network(사설망, 인트라넷)을 가진 본점 및 지점망들간을 다소 고비용의 구축 비용이 필요한 전용회선 보다 저렴한 Public Network(공중망, 인터넷)을 통해서 상호간 통신을 통해서 단일화된 인트라넷을 달성하고 그와 더불어 보안적 요소를 해소하고자 하는 요구에 의해서 개발된 것을 말합니다.

VPN에 대한 기본 설명 영상 (What is a VPN and How Does it Work?)
참고 영상

linux kernel (v5.x)의 xfrm module 관점에서의 IPSec packet 흐름 개요도
참고 그림
Linux Kernel v3.x 기준 Transform packet 흐름 요약
[PNG image (131.6 KB)]
Linux Kernel v5.x 에서의 XDP 및 xfrm(IPSec) 흐름 요약
[PNG image (415.5 KB)]

1.1.1. VPN의 목적

이러한 VPN(Virtual Private Network)을 통해서 전용망에 비하여 얻는 이점과 그에 따른 단점을 다음과 같이 정리해볼 수 있습니다.
VPN(Virtual Private Network)의 장점 및 단점
분류 내용
장점 저비용 구축 및 통신비 절감
Network을 관리하는데 소요되는 운용비용 절감
기업 입장에서 Netowork을 선택하고 교체하는데 필요한 선택기회 증가 (근무자의 위치가 이동하여도 유연하게 대응이 가능)
정보통신 관련 전문기술 활용 가능
단점 공개된 망을 이용함에 따른 보안성 우려
Public Network(공중망, 인터넷)의 여러 외부요인에 의한 불안정성
장비간 호환성
관리의 편의성면에서는 떨어짐
QoS 보장 (Internet은 기본적으로 통제가 되지 않는 신뢰성이 약한 Network들의 모임이기 때문에 안전 및 품질을 보장하기 어렵다는 점)
표준화 (단일화된 표준의 부재)

즉, 각 지점의 Private Network(사설망, 인트라넷)을 Public Network(공중망, 인터넷)을 통해서 하나의 Private Network(사설망, 인트라넷)으로 묶는 표준기술이라고 할 수 있겠으며 전용선에 의한 인트라넷환경에 비하여 저비용 및 유동성을 확보하기 위한 최고의 방법이라고 하겠습니다.
  • 각 지점간 공개망을 통해서 인트라넷을 달성
    • 공개망 이용에 있어서 보안요소 고려가 필요
  • 전용회선에 비하여 저비용 및 유동성을 확보

1.1.2. VPN 주요 용어

1.1.3. VPN의 요소

VPN 사용자의 연결환경에 따라 다음과 같이 분류할 수 있습니다.
  • 인트라넷(Intranet) : 본사와 지사간 내부망으로 구축하려고 하는 환경
  • 원격접속(Remote access) : 원격지(자택, 출장지등)에서 회사 내부망에 접근하려는 직원들의 환경
  • 엑스트라넷(Extranet) : 회사 내부망과 관계사간의 접근을 필요로 하는 환경

VPN은 크게 다음의 요소를 만족시킬 수 있어야 합니다.
  • 인증(Authentication) : 통신하는 상대방이 의도한 상대방이 맞는지를 명확히 확인할 수 있어야 합니다.
    • 인증방식에는 양쪽이 동일한 암호를 공유하는 [https]PSK(Pre-Shared Key)[](https://en.wikipedia.org/wiki/Pre-shared_key)와 디지털 인증서를 사용하는 방식등이 있습니다.
  • 기밀성(Confidentiality) : 상대방과의 통신 내용이 제 3자가 내용을 확인할 수 없도록 암호화가 필요합니다.
    • 암호화 방식에는 [https]DES[](https://en.wikipedia.org/wiki/Data_Encryption_Standard), [https]3DES[](https://en.wikipedia.org/wiki/Triple_DES), [https]AES[](https://en.wikipedia.org/wiki/Advanced_Encryption_Standard), [https]SEED[](https://en.wikipedia.org/wiki/SEED), [https]RC4[](https://en.wikipedia.org/wiki/RC4), ... 등이 있습니다.
  • 무결성(Integrity) : 통신내용의 변조를 방지할 수 있도록 Hash code로 확인하도록 합니다.
    • Hash algorithm으로는 [https]MD5[](https://en.wikipedia.org/wiki/MD5), [https]SHA[](https://en.wikipedia.org/wiki/Secure_Hash_Algorithm), ... 등이 있습니다.
  • 재실행 방지(anti-replay) : 제 3자에 의해서 통신내용에 임의의 패킷제거 또는 패킷삽입을 할 수 없도록 해야 합니다.
    • 패킷의 순번이나 도착시간등을 확인하여 지정한 범위안의 패킷만 처리하도록 하게 되며 [https]ESP[](https://en.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload)등이 활용됩니다.

필요한 주요기술적 관점은 Tunneling, Authentication, Encryption, AccessControl 등이 있습니다.
주요기술적 관점
기술 설명
터널링(Tunneling) 양단간 가상의 통신경로를 설정하는 기술로써 Tunnel의 외부 환경에서는 내부에 있는 Protocol을 파악하기 어렵다는 특징이 있습니다.
인증(Authentication) 외부에서 통신을 변조하지 못하도록 양단간을 확고하게 신뢰할 수 있도록 하여 외부로부터 변조된 내용이 삽입, 누락등을 유도하더라도 이를 판별할 수 있습니다.
암호화(Encryption) 각 Tunnel을 안전하게 보호하기 위해서 암호화 기법을 사용하게 되며 이를 통해서 외부 환경에서는 암호화된 내용을 해독할 수 없습니다.
접근제어(AccessControl) VPN내부 통신자원을 제어하여 불필요한 접근등을 차단하는 기능을 제공합니다.

성능향상에 대한 요구가 매우 크기 때문에 구현시에 다음이 고려되면 좋습니다.
  • crypto H/W 가속기능
  • Multi-core 에 대한 균등한 성능(CPU, IRQ, Memory) 분배 (Lock-less 형태의 설계 고려, RCU...)
  • 할당전략과 Cache에 대한 적절한 안배 및 최소한의 Memory 복사
  • Ethernet port별 담당하는 Controller 에 대한 구성을 이해하고 적절한 port 분배를 명확히 파악필요
  • 하지만 성능이외의 장애발생시에 대처가 가능하도록 적절한 로그 및 오류분석 기법 도입도 반드시 병행
  • 독자적인 성능향상을 도모하기 위해서 이기종간 이식성을 해치는 형태는 깊은 고려가 필요
  • 네트웍 장애시 백업 네트웍에 대한 요구에 대응할 수 있어야 함

1.1.4. VPN의 종류

VPN의 종류는 여러가지가 있으며 몇가지 VPN을 서로 보완적으로 사용하여 구현하는 경우도 있습니다. 아래는 가장 대표적인 VPN을 열거하였습니다.
VPN의 종류
종류 암호화를 수행하는 Layer 주요 용도 비고
[https]IPSec[](https://en.wikipedia.org/wiki/IPsec) VPN (Generic) IPSec VPN Layer 3 이상 본사와 지사간 연결 보통 대규모 VPN에 많이 사용되며 가장 기본적인 VPN이라고 할 수 있습니다.
[https]GRE(Generic Routing Encapsulation)[](https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation) IPSec VPN Layer 3 이상 본사와 지사간 연결 [https]GRE(Generic Routing Encapsulation)[](https://en.wikipedia.org/wiki/Generic_Routing_Encapsulation)를 이용하여 Routing을 해결하는 IPSec VPN
[https]Dynamic Multipoint VPN (DMVPN)[](https://en.wikipedia.org/wiki/Dynamic_Multipoint_Virtual_Private_Network) Layer 3 이상 본사와 지사간 연결 대규모 VPN
IPSec Virtual Tunnel Interface (IPSec VTI) Layer 3 이상 본사와 지사간 연결 설정이 비교적 간편한 VPN
Easy VPN Layer 3 이상 본사와 PC간 연결 외부 근무자에게 내부망으로의 접속을 허용하기 위한 VPN
Flex VPN Layer 3 이상 본사와 지사간 연결 또는 본사와 PC간 연결 IKEv2 기반 통합 VPN
Group Encrypted Transport VPN (Get VPN) Layer 4 이상 본사와 지사간 연결 대규모 VPN, Multicast, QoS지원
[https]SSL[](https://en.wikipedia.org/wiki/Transport_Layer_Security) VPN Layer 5 이상 서버와 PC 연결 전자상거래등의 용도로 많이 사용하며 다양한 정책들을 수립하기 좋습니다.
[https]PPTP[](https://en.wikipedia.org/wiki/Point-to-Point_Tunneling_Protocol) VPN Layer 2 이상 본사와 PC 연결 외부근무자에게 내부망으로의 접속을 허용하기 위해서 많이 사용합니다.
[https]L2TP[](https://en.wikipedia.org/wiki/Layer_2_Tunneling_Protocol) VPN Layer 2 이상 본사와 PC 연결 외부근무자에게 내부망으로의 접속을 허용하기 위해서 많이 사용하지만 요즘에는 비교적 많이 쓰이지는 않습니다.
[https]MPLS[](https://en.wikipedia.org/wiki/Multiprotocol_Label_Switching) VPN 암호화 하지 않음 본사와 지사간 연결 보통은 ISP측에서 제공하므로 사용자 입장에서는 별도의 장비구입이 필요없는 경우가 대부분이며, IPSec VPN과 함께 사용합니다.

1.2. IPSec VPN

1.2.1. IPSec VPN 관련 주요 표준

1.2.2. 구성요소

  • 통신의 첫 시작에서 상대방을 인증하고 보안통신에 필요한 보안정책 집합인 [https]SA(Security Association)[](https://en.wikipedia.org/wiki/Security_association)를 결정하며 필요한 여러 Key를 결정하기 위하여 [https]IKE(Internet Key Exchange)[](https://en.wikipedia.org/wiki/Internet_Key_Exchange)와 ISAKMP (Internet Security Association and Key Management Protocol)을 사용합니다.
  • 보안통신을 위해 필요한 여러가지 알고리즘(algorithm)과 정책들의 집합을 [https]SA(Security Association)[](https://en.wikipedia.org/wiki/Security_association)라고 하며 이를 사용하게 됩니다. 여기서 이것을 하나의 코드로 표시한 것을 [https]SPI(Security Parameter Index)[](https://en.wikipedia.org/wiki/Security_Parameter_Index)라고 합니다.
  • 실제 Data를 보호하기 위하여 암호화하고 무결성을 확인하는 기능이 있는 [https]ESP(Encapsulation Security Protocol)[](https://en.wikipedia.org/wiki/IPsec#Encapsulating_Security_Payload)를 사용하거나 개별 패킷의 무결성만을 확인하는 [https]AH(Authentication Header)[](https://en.wikipedia.org/wiki/IPsec#Authentication_Header)을 사용합니다. [https]AH(Authentication Header)[](https://en.wikipedia.org/wiki/IPsec#Authentication_Header)는 암호화 기능이 없어 기밀성(Confidentiality)을 보완하기 위한 방법(AH + ESP 조합하는 방법)를 별도로 추가도입하지 않으면 대체적으로 잘 사용하지 않는 편입니다.

1.2.3. ISAKMP (~= IKEv1, Internet Security Association and Key Management Protocol)

  • [https]RFC2408 - Internet Security Association and Key Management Protocol[](https://tools.ietf.org/html/rfc2408) 는 통신하고자 하는 양단간에 통신을 보호하기 위한 보안통신을 달성하기 위해서 필요한 암호화 및 무결성 확인을 방법이 정해지도록 일련의 절차들이 필요한데 이와 같은 일을 하도록 절차를 명시한 Protocol 이라고 할 수 있습니다.
  • 이와 혼용해서 많이 표현되는 것중에 [https]RFC2409 - The Internet Key Exchange[](https://tools.ietf.org/html/rfc2409) 가 있으며 이것은 ISAKMP가 명시한 절차에 필요한 구체적인 Protocol의 종류와 사용방법등을 정의한 것입니다. 그러나 이 둘간의 유사성이 매우 커서 2010년 9월에 개정된 [https]RFC5996 - Internet Key Exchange Protocol Version 2[](https://tools.ietf.org/html/rfc5996) 에서 IKE와 ISAKMP를 통합하여 정의하게 되었습니다.
  • 보안을 만족하는 통신을 위해서 필요한 일련의 Protocol, Algorithm, Key, 그외의 속성들을 [https]SA(Securify Association, 보안 관련 집합정보)[](https://en.wikipedia.org/wiki/Security_association)라고 하며 송신자와 수신자가 안전하게 이러한 정보를 교환하기 위해서 SA 및 Session-Key를 관리(생성, 협상, 삭제)할 수 있도록 하는 Protocol 중 하나가 ISAKMP라고 합니다.
  • 대표적으로 IPSEC으로 통신하고자 하는 양단을 구현하기 위해서는 상호간 보안협상(Securify Association)이 필요하며 이를 위해서 구체적인 Protocol은 IKE를 이용하고 Packet의 format은 ISAKMP의 형식을 준수하도록 구현하여 이를 달성하게 됩니다.
1.2.3.1. ISAKMP의 역할
ISAKMP_Placement.png
[PNG image (26.5 KB)]


  • ISAKMP는 기본적으로 모든 전송 Protocol 또는 IP를 통해서 구현될수 있습니다.
    • UDP port 500에서 송신 및 수신이 가능한 동작을 기반으로 한 구현을 반드시 포함해야 합니다.
    • NAT (Network Address Translation) 환경이 감지되면 UDP port 4500에서 동작하기도 합니다.
  • "DOI Definition"는 실제 통신에 사용되는 값들이 어떤 구조하에 어떤 의미로 사용되는지를 정의해 놓은 것을 말합니다.
  • "Key Exchange Definition"은 Diffie-Hellman Key Agreement Method (Diffie-Hellman 키 분배 방법)과 같은 Key교환에 대한 방법을 말합니다.
  • "API"는 ISAKMP와 Security Protocol과의 Interface 를 말합니다.
    • Linux의 경우 Netlink를 통한 xfrm module과의 Interface 나 PF_KEY를 통한 Key관리등이 있습니다.
  • "Security Protocol"은 AH(Authentication Header) 이나 ESP(Encapsulating Security Payload) 와 같은 IP level (OSI Layer 3) 에서 동작하는 보안 Protocol 규약들을 말합니다.
1.2.3.2. ISAKMP의 기본 충족 요건
Message를 교환하는데 있어서 [https]강한인증(strong authentication)[](https://en.wikipedia.org/wiki/Strong_authentication)기능을 제공해야 하며 이를 위해서 다음을 만족하도록 정의됩니다.

  • IP주소등이 위조가 가능하지 않도록 합니다.
  • 암호학적인 요소로 보호되는 방식을 포함합니다.
  • 디지털 서명 알고리즘을 지원해야 하지만, 특정한 알고리즘에 제약되어 제한을 두지는 않습니다.
  • 모든 전송 protocol을 통해서 구현이 가능하지만 모든 구현에는 UDP port 500번을 사용하는 송신 및 수신 기능이 포함되어야 합니다.
1.2.3.3. 키 교환(Key exchange) 요소
  • 키 설정 (Key establishment)
    • 키 생성(Key generation)
    • 키 전달(Key transportation)
      • 송신자가 임의의 Session Key를 생성한 후 수신자의 공개키로 암호화하여 상대방에게 전달하고 수신자는 이를 자신의 비밀키로 복호화하여 Session Key를 알아낼 수 있는 방법입니다.
  • 키 교환 인증 (Key exchange Authentication)
    • Key를 교환 중이거나 교환이 완료된 이후에도 발신자를 인증할 수 있어야 합니다.
    • Key 교환이 완료되기 전에 Session Key를 가지고 있다는 것을 증명하는 방법의 경우 인증되지 않은 Message에 대한 불필요한 컴퓨팅 자원을 소모하지 않도록 할 수 있어 키 교환을 완료 후 인증하는 것보다 유용합니다.
  • 키 교환 대칭성 (Key exchange symmetry)
    • 키 교환하는 양쪽중에 어디서나 키 교환을 시작할 수 있는 성질을 말하는데 누가 키 교환을 시작했는지와 상관없도록 하는 것이기에 [https]반향공격(Reflection attack)[](https://en.wikipedia.org/wiki/Reflection_attack) 에 대한 취약성에 유의해야 합니다.
1.2.3.4. 키교환 과정
IKE(Internet Key Exchange)는 기본적으로 크게 2단계(two phases) 과정으로 나뉩니다. 여기에 추가적인 선택적 단계가 있습니다. ☞ 일부 문서에서는 1.5단계와 2단계를 각각 2단계와 3단계로 명시하기도 하므로 각 문서의 취지에 맞게 혼동되지 않게 이해하는 노력이 필요합니다.

  • 키교환 단계1(Phase 1) 에서는 키교환 단계2(Phase 2)에서 협상(Negotiation)하는 일련의 과정들을 보호하기 위해서 사용될 [https]SA(Security Association)[](https://en.wikipedia.org/wiki/Security_association) 를 생성하여 교환하는 과정이며 단계2(Phase 2)의 협상(Negotiation)할 때의 정보들을 암호화 하는데 사용됩니다.
    • 쌍방간의 IKE SA(Security Association)가 설정됩니다.
      • 인증에 필요한 요소들 (Authentication method)
        • Ex) pre-shared key, RSA signature, …
      • 양단(End-point)간의 유효성을 확인하기 위한 요소들 (Hash algorithm)
      • 암호/복호에 사용될 알고리즘 요소들 (Encryption algorithm)
        • Ex) DES, 3DES, AES, …
      • 키를 교환하는데 사용할 요소들 (Diffie-Hellman group information)
        • Ex) group 1, group 2, group 5, group 14, …
      • 키의 유효시간을 결정하는 요소들 (Life time/size of the IKE SA)
    • Main mode 와 Agressive mode 2가지의 모드가 여기에 속합니다.
  • 키교환 선택적 단계(Optional Phase 1.5) 에서는 추가 인증을 달성합니다. (☞ 이 단계는 선택사항입니다.)
    • XAuth 추가 인증 Layer 를 달성합니다.
    • XAuth는 End-point뒤의 사용자에게도 인증하게 합니다.
  • 키교환 단계2(Phase 2) 에서 생성 및 교환된 [https]SA(Security Association)[](https://en.wikipedia.org/wiki/Security_association)는 안전하게 보호될 수 있으며 이를 이용하여 실제 Data의 통신을 보호 할 수 있게 됩니다.
    • 키교환 1단계(phase 1)에서 설정된 IKE SA(Security Association)을 사용하여 양단(End-point)사이의 각 방향에 따른 단방향 IPSec SA(Security Association)를 각각 달성합니다.
    • Quick mode 모드가 여기에 속합니다.
1.2.3.5. 키교환 모드
IKEv1에서는 1단계(phase 1)와 선택적 단계(phase 1.5)에서는 Main mode 와 Agressive mode 2가지의 모드가 사용되며 2단계(phase 2)에서는 Quick mode가 사용됩니다.

IKEv1이 처음 탄생되었을 때에는 IKE와 IPSec 간의 강력한 분리를 고려했었습니다. 이것은 어디까지나 IPSec 이외의 다른 형태가 탄생할 수 있을거라는 예상을 하고 고려하기 위함이었습니다. 하지만 이후 결과적으로 IPSec이외에는 IKE를 사용하는 경우가 없다고 판단되었고 IKE SA와 IPSec SA 협상을 간결하게 하나의 교환 묶음으로 결합해도 좋을거 같다는 취지하에 IKEv2가 새로이 탄생 된 것입니다.

IKEv2에서는 Main mode 및 Aggressive mode와 유사하지 않으며 Quick mode에 대한 개념도 없습니다. 즉, 한가지 mode(IKEv2 initial exchanges)뿐이어서 별도의 mode로 분류할 이유도 없고 mode로 언급도 하지 않습니다.
IKEv2_Initial_exchanges_Overview.gif
[GIF image (34.48 KB)]
1.2.3.6. IKEv1 Main mode
IKEv1_Main_mode_Overview.gif
[GIF image (29.18 KB)]


3개의 쌍으로 된 총 6개의 Message로 구성됩니다.
  • Main mode를 선택한다면 Aggressive mode는 사용되지 않습니다.
    • Quick mode는 항상 Main mode에 따릅니다.
    1.2.3.7. IKEv1 Aggressive mode
    IKEv1_Aggressive_mode_Overview.gif
    [GIF image (28.44 KB)]


    Main mode에서 6개의 Message 를 3개의 Message로 단축한 구성입니다. IKEv1 Aggressive mode 특징 - Main mode와 비교할 때 큰 차이점은 다음과 같습니다.
    • Message의 수가 절반 밖에 되지 않아 Exchange 속도가 빠를 수 있음을 기대할 수 있습니다.
      • Initiator가 Responder 의 policy 를 알고 있는 경우 좀더 빠른 Exchange를 기대하기 위해서 사용합니다.
    • 처음 Message에서 Diffie-Hellman 공유 값과 nonce(임의의 난수에 의해서 산출되는 data) 값을 제공해야 하기 때문에 협상 능력(Group description)을 제한 받습니다.
      • Identity Protection을 할 수 없습니다.
    • Pre-shared Key 인증을 사용하면서 Initiator의 IP주소를 알 수 없는 환경(Dial-up환경 등)에서 사용할 수 있는 유일한 방법입니다.
    • Pre-shared key 가 Encrypt로 보호받지 못합니다.
      • 기본적으로 보안문제가 있는데 이는 Pre-shared key 에 대한 hash 값이 그대로 노출된다는 것이고 공격자는 이를 가로채어 해당 Hash로부터 역으로 Pre-share key 를 유추할 수 있게 되어 보안이 취약하게 됩니다.
      • 공격자에게 Aggressive mode 특성상 PSK의 Hash값이 그대로 노출되고 공격자는 오프라인 상태에서 강력한 컴퓨팅 파워로 이 Hash값에 대한 역방향 Pre-shared key 목록을 뽑아낼 수 있습니다. 그렇게 되면 해당 목록 몇개만 시도해보면 키 교환이 성공할 수 있는 가능성이 존재한다는 겁니다. (운영자는 PSK로 사용시 비교적 빠른 주기로 PSK를 바꿔야 하며 비교적 복잡한 조합과 함께 긴 PSK를 사용해야 하는 부담을 감수해야만 그나마 공격을 어렵게 만들기는 하겠지만 근본적인 취약점이 존재한다고 볼 수 있습니다.)
      • IKEv1에만 Aggressive mode가 있고 IKEv2에는 이러한 mode가 없는 이유이기도 합니다.
    1.2.3.8. IKEv1 Quick mode
    IKEv1_Quick_mode_Overview.gif
    [GIF image (36.04 KB)]


    이 모드는 1단계(phase 1)에서 협상된 IKE SA에 의해서 보호되며 Data 암호화에 대한 협상을 하며 여기에 필요한 IPSec SA를 교환합니다.
    • Protocol (AH, ESP, both AH and ESP, …)
    • Authentication algorithm (Hmac-Md5, Hmac-Sha, …)
    • Encapsulation mode (tunnel, transport, …)
    • Encryption algorithm (DES, 3DES, AES, …)
    • Diffie-Hellman group info (group 1, group 2, group 5, group 14, …)
      • Diffie-Hellman 교환에서 생성된 Session Key는 IPSec SA의 키를 생성하기 위한 부분에 사용되며 이를 통하여 [https]PFS(Perfect Forward Secrecy)[](https://en.wikipedia.org/wiki/Forward_secrecy)를 달성합니다.
    • IPSec SA의 유효시간(Life time) 과 유효크기(life size) 결정
    1.2.3.9. [https]SA (Security Association, 보안 관련 집합정보)[](https://en.wikipedia.org/wiki/Security_association) 요소
    • SPI (Security Parameter Index, 32-bits) (참고: [https]RFC4303 - Section 2.1. Security Parameters Index[](https://tools.ietf.org/html/rfc4303#section-2.1))
      • SA를 검색 및 식별하기 위해서 각 보안 프로토콜들은 SPI를 나타내는 영역을 가지고 있으며 이는 시스템 내에서 유일한 값으로 사용합니다.
    • DOI (Domain of Interpretation) (참고: [https]RFC2407[](https://tools.ietf.org/html/rfc2407))
      • 다음 요구사항에 대한 규약(Convention)을 말합니다. (해석하는 기준을 정의한 집합)
        • define the naming scheme for DOI-specific protocol identifiers
        • define the interpretation for the Situation field
        • define the set of applicable security policies
        • define the syntax for DOI-specific SA Attributes (Phase II)
        • define the syntax for DOI-specific payload contents
        • define additional Key Exchange types, if needed
        • define additional Notification Message types, if needed
    • Situation (참고: [https]RFC2407 - Section 4.2. IPSEC Situation Definition[](https://tools.ietf.org/html/rfc2407#section-4.2))
      • 협상에 필요한 보안 서비스를 결정하기 위해서 필요한 모든 정보를 말합니다.
    • Exchange Type
      • 메세지의 수와 Payload들이 정의되며 익명성, [https]PFS(Perfect Forward Secrecy)[](https://en.wikipedia.org/wiki/Forward_secrecy), 인증등의 서비스를 달성하기 위해서 메세지의 교환 형태가 정의된 것을 말합니다.
    • Payload
      • DOI (Domain of Interpretation)에서 여러종류의 payload 들이 정의되고 [https]SA(Security Association, 보안 관련 집합정보)[](https://en.wikipedia.org/wiki/Security_association) 내용 및 키 교환을 위한 내용들을 전송하기 위해서 생성 및 해석을 합니다.
    • 제안 및 협상 (Proposal)
      • 제안자가 선택할 수 있는 요소들을 열거하고 이들 중에서 수신자가 선호하거나 가능한 요소들를 선택하도록 하여 제안자와 수신자가 가장 선호하는 형태의 구현을 선택하도록 하는 것을 말합니다.
    1.2.3.10. ISAKMP Header Format with payload
    ISAKMP message preview
    MAC header IP header UDP header ISAKMP packet
    1.2.3.11. ISAKMP Header Format
    ISAKMP message는 다음과 같은 header(HDR) 구조에 맞춰 교신을 시작하며 추가적인 payload가 뒤따를 수 있습니다. (참고: [https]RFC2408 Section 3.1 ISAKMP Header Format[](https://tools.ietf.org/html/rfc2408#section-3.1))
    ISAKMP message
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Initiator Cookie
    (8 octets)
    Responder Cookie
    (8 octets)
    Next Payload (1 octet) Major version (4 bits) Minor version (4 bits) Exchange Type (1 octet) Flags (1 octet)
    Message ID (4 octets)
    Length (4 octets)
    • "Initiator Cookie" : ISAKMP SA를 시작하는 Initiator가 붙이는 식별자입니다. SA에 대한 통보나 삭제등에 사용됩니다.
    • "Responder Cookie" : ISAKMP SA를 수신하는 Responder가 붙이는 식별자입니다. SA에 대한 통보나 삭제등에 사용됩니다.
    • "Next payload" : 다음에 오는 첫번째 Payload의 유형를 나타냅니다.
      Next payload
      값 의미
      0 NONE (No Next Payload)
      1 Security Association (SA, [https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      2 Proposal (P, [https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      3 Transform (T, [https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      4 Key Exchange (KE, [https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      5 Identification (ID: IDi/IDr, [https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      6 Certification (CERT, [https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      7 Cerificate Request (CR, [https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      8 Hash (HASH) (AUTH, [https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      9 Signature (SIG, [https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      10 Nonce (NONCE, [https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      11 Notification (N, [https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      12 Delete (D, [https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      13 Vendor (VID, [https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      14 Attributes Payload (ISAKMP Mode Config, aka configuration payload, [https]https://tools.ietf.org/tools/rfcmarkup/rfcmarkup.cgi?draft=draft-ietf-ipsec-isakmp-mode-cfg-05.txt[])
      15 SA KEK Payload (SAK, [https]RFC3547[](https://tools.ietf.org/html/rfc3547), [https]RFC6407[](https://tools.ietf.org/html/rfc6407))
      16 SA TEK Payload (SAT, [https]RFC3547[](https://tools.ietf.org/html/rfc3547), [https]RFC6407[](https://tools.ietf.org/html/rfc6407))
      17 Key Download (KD, [https]RFC3547[](https://tools.ietf.org/html/rfc3547))
      18 Sequence Number (SEQ, [https]RFC3547[](https://tools.ietf.org/html/rfc3547))
      19 Proof of Possession (POP, [https]RFC3547[](https://tools.ietf.org/html/rfc3547))
      20 NAT Discovery (NAT-D, [https]RFC3947[](https://tools.ietf.org/html/rfc3947))
      21 NAT Original Address (NAT-OA, [https]RFC3947[](https://tools.ietf.org/html/rfc3947))
      22~32 RESERVED
      33 Security Association (SA, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      34 Key Exchange (KE, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      35 Identification - Initiator (IDi, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      36 Identification - Responder (IDr, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      37 Certificate (CERT, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      38 Certificate Request (CERTREQ, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      39 Authentication (AUTH, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      40 Nonce (Ni/Nr, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      41 Notify (N, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      42 Delete (D, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      43 Vendor ID (V, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      44 Traffic Selector - Initiator (TSi, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      45 Traffic Selector - Responder (TSr, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      46 Encrypted and Authenticated (SK, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      47 Configuration (CP, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      48 Extensible Authentication (EAP, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      49 Generic Secure Password Method (GSPM, [https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      50 Group Identification (IDg, draft-yeung-g-ikev2)
      51 Group Security Association (GSA, draft-yeung-g-ikev2)
      52 Key Download (KD, draft-yeung-g-ikev2)
      53 Encrypted and Authenticated Fragment (SKF, [https]RFC7383[](https://tools.ietf.org/html/rfc7383))
      54 Puzzle Solution (PS, [https]RFC8019[](https://tools.ietf.org/html/rfc8019))
      55~127 RESERVED
      128~255 Private Use
    • Major / Minor version field
      • "Major version" : ISAKMP표준에 맞게 구현했다면 1(또는 2), 그렇지 않은 경우는 0입니다.
      • "Minor version" : ISAKMP표준에 맞게 구현했다면 0, 그렇지 않은 경우는 1입니다.
      • 즉, ISAKMP 표준에 맞게 구현했다면 1.0(또는 2.x)으로 기술되며 그렇지 않은 경우 0.1로 기술된다는 것입니다.
    • "Exchange Type" : Message의 교환 유형를 나타냅니다.
      Exchange Type
      IKEv1
      값 의미
      0 None ([https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      1 Base ([https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      2 Identify Protection ([https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      3 Authentication Only ([https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      4 Aggressive ([https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      5 Informational ([https]RFC2408[](https://tools.ietf.org/html/rfc2408))
      6~31 ISAKMP Future Use
      32 Quick Mode ([https]RFC2409[](https://tools.ietf.org/html/rfc2409))
      33 New Group Mode ([https]RFC2409[](https://tools.ietf.org/html/rfc2409))
      34 IKE_SA_INIT ([https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      35 IKE_AUTH ([https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      36 CREATE_CHILD_SA ([https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      37 INFORMATIONAL ([https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      38 IKE_SESSION_RESUME ([https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      39 GSA_AUTH (draft-yeung-g-ikev2)
      40 GSA_REGISTRATION (draft-yeung-g-ikev2)
      41 GSA_REKEY (draft-yeung-g-ikev2)
      42~239 DOI(Domain of Interpretation) Specific Use (RESERVED TO IANA)
      240~255 Reserved for private use
      • "Base" 교환 : 4개의 Message로 구성됩니다.
      • "Identify Protection" 교환 : 기본적으로 Base와 전달되는 Payload들은 같지만 6개의 Message로 구성됩니다.
      • "Authentication Only" 교환 : Key 를 생성하지 않고 인증만을 위해서 사용되는 Message 교환입니다.
      • "Aggressive" 교환 : 3개의 Message만으로 상대방을 인증하고 SA의 보호를 위한 Key까지 생성합니다.
      • "Informational" 교환 : 일방적으로 단순히 정보를 전달(Notification)하거나 특정 SA를 지우는(Delete) 명령을 보내고 끝냅니다.
    • "Flags" : Message의 교환 형태에 필요한 특정 옵션을 나타냅니다.
      Flags
      Bit(0 ~ 7) 의미
      0 E(ncryption Bit)
      1 C(ommit Bit)
      2 A(uthentication Only Bit)
      3 ~ 7 RESERVED(항상 0으로 설정되어 있어야 함)
    • "Message ID" : Phase2 (2단계) Message 교환을 위해서 사용하는 ID입니다. Phase1 (1단계) Message 교환중에는 이 값이 반드시 0이어야 합며 Phase2(2단계) 협상과정중에 Protocol의 상태를 나타내주는 Unique한 Message Identifier로 이용됩니다. 이 값은 Initiator가 난수(Random)값으로 생성합니다.
    • "Length" : Header를 포함한 전체 Message의 길이(Header size + Payload size) 를 octet단위로 나타냅니다.
    1.2.3.12. Generic Payload Header
    모든 Payload들은 다음과 같이 Generic Payload Header구조로 나타내며 Next payload에 의해서 Chaining방식으로 packet을 build할 수 있습니다. (참고: [https]RFC2408 Section 3.2 Generic Payload Header[](https://tools.ietf.org/html/rfc2408#section-3.2))
    Generic Payload Header
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) RESERVED (1 octet) Payload Length
    (Payload)
    • "Next Payload" : 다음 Payload의 유형이며 마지막 Payload에서는 이 값이 0(NONE)으로 표시되어야 합니다. 이 값에 의해서 다음 Payload가 연달아서 연결되어 올 수도 있다는 것을 알 수 있습니다.
    • "RESERVED" : 반드시 0으로 설정되어야 합니다.
    • "Payload length" : Header를 포함한 길이(Header size + Payload size) 를 octet단위로 나타냅니다.
  • 즉, 예를 들자면 다음과 같은 형태로 packet이 빌드됩니다.

    ISAKMP_payload_chaining.png
    [PNG image (49.47 KB)]
    • 1.2.3.13. Data Attributes
    ISAKMP Payload안에는 여러가지 속성들(Attributes)이 기술되어야 할 필요가 있습니다. 이 경우 속성값들을 표현하기 위해서 다음과 같은 구조로 나타냅니다. (참고: [https]RFC2408 Section 3.3 Data Attributes[](https://tools.ietf.org/html/rfc2408#section-3.3))
    Data Attributes
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    AF (1 bit) Attribute Type (15 bits) AF=0 ? Attibute Length (2 octets)
    AF=1 ? Attribute Value (2 octets)
    AF=0 ? Attibute Value (Variable size: Attibute Length)
    AF=1 ? Not Transmitted
    • "AF" : 0인 경우 "Attribute Length"에 의한 가변 크기의 Data를 Attibute Value로 나타낼 수 있으며 1인 경우 고정된 2 octets크기의 Data를 나타내도록 합니다.
    • "Attribute Type" : 표현하고자 하는 속성의 식별값이며 DOI(Domain of Interpretation)에 정의되어 있습니다.
    • "Attribute Length" : "AF"가 0 인 경우 실제 Data 의 길이를 나타냅니다. "AF"가 1인 경우 2 octets 크기의 값을 나타낼 수 있습니다.
    • "Attribute Value" : "AF"가 0 인 경우 "Attribute Length"에 명시한 크기만큼의 Data를 나타냅니다.
    1.2.3.14. Security Association Payload
    이 payload는 Security Attribute들, DOI에서 정의하는 사항, 협상에 대한 Situation등을 명시합니다. (참고: [https]RFC2408 Section 3.4 Security Association Payload[](https://tools.ietf.org/html/rfc2408#section-3.4))
    Security Association Payload
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) RESERVED (1 octet) Payload Length
    Domain of Interpretation (DOI) (4octets)
    (Situation) (Variable length)
    • "DOI" : 32bit 부호없는 정수형이며 1단계(Phase 1)중에는 0의 값으로 지정하며 2단계(Phase 2) 과정중에 IPSec을 기술하기 위해서 1의 값을 지정합니다. (IPSec 뿐만 아니라 SNMPv3, RIPv3등의 보안이 적용되는 다양한 프로토콜이 적용될 수 있기 때문에 해당하는 Payload에 어떤 프로토콜에 대한 내용을 담는지를 DOI로 지정하게 됩니다.)
      • 값이 0인 경우는 "Generic ISAKMP SA"를 지칭합니다.
      • 값이 1인 경우는 "IPSec DOI"([https]RFC2407 - The Internet IP Security Domain of Interpretation for ISAKMP[](https://tools.ietf.org/html/rfc2407))를 지칭합니다.
      • 그 밖에 나머지는 IANA에서 미래를 위해서 예약된 값이며 RFC와 같은 사양을 연계참조하지 않고 임의로 값을 할당하지는 않습니다.
    • "Situation" : DOI에서 지정한 필드규격에 맞게 가변길이로 표현됩니다. (참고: [https]RFC2407 Section 4.6.1 Security Association Payload[](https://tools.ietf.org/html/rfc2407#section-4.6.1))

    1.2.4. IKEv2 ([https]RFC7296 - Internet Key Exchange Protocol Version 2[](https://www.rfc-editor.org/rfc/rfc7296))

    1.2.4.1. IKE Header Format
    IKE Header Format
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    IKE SA Initiator's SPI
    (8 octets)
    IKE SA Responder's SPI
    (8 octets)
    Next Payload (1 octet) Major version (4 bits) Minor version (4 bits) Exchange Type (1 octet) Flags (1 octet)
    Message ID (4 octets)
    Length (4 octets) 
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       IKE SA Initiator's SPI                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       IKE SA Responder's SPI                  |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  Next Payload | MjVer | MnVer | Exchange Type |     Flags     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Message ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Length                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    • "IKE SA Initiator's SPI" : Initiator의 IKE Security Association 에 대한 고유한 값 (SPI)입니다. 이 값은 항상 0이 아닌 값이어야 합니다.
    • "IKE SA Responder's SPI" : Responder의 IKE Security Association 에 대한 고유한 값 (SPI)입니다. 이 값은 Initiator에서 Responder로의 첫 메세지 (Cookie가 포함된 메세지의 반복 포함) 에서는 0이어야 합니다.
    • "Next payload" : 다음에 오는 첫번째 Payload의 유형를 나타냅니다.
    • Major / Minor version field
      • "Major version" : ISAKMP표준에 맞게 구현했다면 1(또는 2), 그렇지 않은 경우는 0입니다.
      • "Minor version" : ISAKMP표준에 맞게 구현했다면 0, 그렇지 않은 경우는 1입니다.
      • 즉, ISAKMP 표준에 맞게 구현했다면 1.0 또는 2.x으로 기술되며 그렇지 않은 경우 0.1로 기술된다는 것입니다.
    • "Exchange Type" : Message의 교환 유형를 나타냅니다.
      Exchange Type
      IKEv1
      값 의미
      34 IKE_SA_INIT ([https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      35 IKE_AUTH ([https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      36 CREATE_CHILD_SA ([https]RFC7296[](https://tools.ietf.org/html/rfc7296))
      37 INFORMATIONAL ([https]RFC7296[](https://tools.ietf.org/html/rfc7296))
    • "Flags" : Message의 교환 형태에 필요한 특정 옵션을 나타냅니다.
      Flags
      Bit(0 ~ 7) 의미
      0 X (0 cleared and ignored)
      1 X (0 cleared and ignored)
      2 X (0 cleared and ignored)
      3 I (Initiator)
      4 V (Version)
      5 R (Response)
      6 X (0 cleared and ignored)
      7 X (0 cleared and ignored)
      • "X" : 0으로 초기화하거나 이 값을 무시하도록 해야 합니다.
      • "I (Initiator)" : (Original) Initiator 가 전송하는 메세지는 1, (Original) Responder 가 전송하는 메세지는 0이어야 합니다.
      • "V (Version)" : Major version 보다 더 높은 프로토콜의 Major version을 명시할 때 1로 설정할 수 있습니다. IKEv2 는 0으로 설정하거나 무시합니다.
      • "R (Response)" : 모든 요청 패킷에는 0, 모든 응답 패킷에는 1로 설정합니다.
    • "Message ID" : 손실된 패킷의 재전송과 요청 및 응답의 일치를 제어하는 데 사용되는 메시지 식별자입니다.
    • "Length" : Header를 포함한 전체 Message의 길이(Header size + Payload size) 를 octet단위로 나타냅니다.
    1.2.4.2. Generic Payload Header
    Generic Payload Header
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) Critical (1 bit) RESERVED (7 bits) Payload Length (2 octets)
    (Payload)
    • "Next Payload" : 다음 Payload의 유형이며 마지막 Payload에서는 이 값이 0(NONE)으로 표시되어야 합니다. 이 값에 의해서 다음 Payload가 연달아서 연결되어 올 수도 있다는 것을 알 수 있습니다.
      Next Payload Type
      표기법(Notation) 값 의미
      - 0No Next Payload
      SA 33Security Association
      KE 34Key Exchange
      IDi 35Identification - Initiator
      IDr 36Identification - Responder
      CERT 37Certificate
      CERTREQ 38Certificate Request
      AUTH 39Authentication
      Ni, Nr 40Nonce
      N 41Notify
      D 42Delete
      V 43Vendor ID
      TSi 44Traffic Selector - Initiator
      TSr 45Traffic Selector - Responder
      SK 46Encrypted and Authenticated
      CP 47Configuration
      EAP 48Extensible Authentication
      • IKEv1에 대한 코드 할당과 겹치지 않도록 향후 페이로드 유형 값 1-32는 할당하지 않아야 합니다.
    • "Critical" : 송신자가 이전 Payload의 Next Payload 에 있는 Payload Type 코드를 이해하지 못하는 경우 수신자가 이 Payload를 건너뛰기(skip)를 원하는 경우 반드시 0으로 설정해야 합니다
      • 송신자가 Payload Type을 이해하지 못하는 경우 수신자는 이 전체 메시지를 거부(reject)하기를 원하는 경우 1로 설정해야 합니다. 수신자가 Payload Type을 이해하는 경우에는 이를 무시(ignored)해야 합니다.
      • [https]RFC7296[](https://www.rfc-editor.org/rfc/rfc7296) 에 정의된 Payload Type은 0으로 설정해야 합니다.
    • "RESERVED" : 반드시 0으로 설정되어야 합니다.
    • "Payload Length" : Generic Payload Header 크기를 포함한 Payload 크기를 octet 단위로 지정합니다.
    1.2.4.3. Generic Attributes Format
    Payload 및 하위 구조화(Substructure)된 내부에는 여러가지 및 속성들(Attributes, 예: Transform Attributes)이 기술되어야 할 필요가 있습니다. 이 경우 속성값들을 표현하기 위해서 다음과 같은 구조로 나타냅니다.
    Data Attributes
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    AF (1 bit) Attribute Type (15 bits) AF=0 ? Attibute Length (2 octets)
    AF=1 ? Attribute Value (2 octets)
    AF=0 ? Attibute Value (Variable size: Attibute Length)
    AF=1 ? Not Transmitted
    • "AF" : 0인 경우 "Attribute Length"에 의한 가변 크기의 Data를 Attibute Value로 나타낼 수 있으며 1인 경우 고정된 2 octets크기의 Data를 나타내도록 합니다.
    • "Attribute Type" : 표현하고자 하는 속성의 식별값이며 DOI(Domain of Interpretation)에 정의되어 있습니다.
    • "Attribute Length" : "AF"가 0 인 경우 실제 Data 의 길이를 나타냅니다. "AF"가 1인 경우 2 octets 크기의 값을 나타낼 수 있습니다.
    • "Attribute Value" : "AF"가 0 인 경우 "Attribute Length"에 명시한 크기만큼의 Data를 나타냅니다.
    1.2.4.4. Security Association Payload
       SA Payload
      |
      +--- Proposal #1 ( Proto ID = ESP(3), SPI size = 4,
      |     |            7 transforms,      SPI = 0x052357bb )
      |     |
      |     +-- Transform ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Attribute ( Key Length = 128 )
      |     |
      |     +-- Transform ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Attribute ( Key Length = 192 )
      |     |
      |     +-- Transform ENCR ( Name = ENCR_AES_CBC )
      |     |     +-- Attribute ( Key Length = 256 )
      |     |
      |     +-- Transform INTEG ( Name = AUTH_HMAC_SHA1_96 )
      |     +-- Transform INTEG ( Name = AUTH_AES_XCBC_96 )
      |     +-- Transform ESN ( Name = ESNs )
      |     +-- Transform ESN ( Name = No ESNs )
      |
      +--- Proposal #2 ( Proto ID = ESP(3), SPI size = 4,
            |            4 transforms,      SPI = 0x35a1d6f2 )
            |
            +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
            |     +-- Attribute ( Key Length = 128 )
            |
            +-- Transform ENCR ( Name = AES-GCM with a 8 octet ICV )
            |     +-- Attribute ( Key Length = 256 )
            |
            +-- Transform ESN ( Name = ESNs )
            +-- Transform ESN ( Name = No ESNs )
    • Proposal Substructure
      Proposal Substructure
      0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
      Last Substruc (1 octet) RESERVED (1 octet) Proposal Length (2 octets)
      Proposal Num (1 octet) Protocol ID (1 octet) SPI Size (1 octet) Num Transforms (1 octet)
      SPI (variable)
      <Transforms> (variable)
    • Transform Substructure
      Transform Substructure
      0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
      Last Substruc (1 octet) RESERVED (1 octet) Transform Length (2 octets)
      Transform Type (1 octet) RESERVED (1 octet) Transform ID (2 octets)
      Transform Attributes (variable)
    • Transform Attributes
    1.2.4.5. Key Exchange Payload
    Key Exchange Payload Format
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) Critical (1 bit) RESERVED (7 bits) Payload Length (2 octets)
    Diffie-Hellman Group Num (2 octets) RESERVED (2 octets)
    Key Exchange Data (variable)
    1.2.4.6. Identification Payloads
    Identification Payload Format
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) Critical (1 bit) RESERVED (7 bits) Payload Length (2 octets)
    ID Type (1 octet) RESERVED (3 octets)
    Identification Data (variable)
    1.2.4.7. Certificate Payload
    Certificate Payload Format
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) Critical (1 bit) RESERVED (7 bits) Payload Length (2 octets)
    Cert Encoding (1 octet) Certificate Data (variable)
    Certificate Data (...)
    1.2.4.8. Certificate Request Payload
    Certificate Request Payload Format
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) Critical (1 bit) RESERVED (7 bits) Payload Length (2 octets)
    Cert Encoding (1 octet) Certification Authority (variable)
    Certification Authority (...)
    1.2.4.9. Authentication Payload
    Authentication Payload Format
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) Critical (1 bit) RESERVED (7 bits) Payload Length (2 octets)
    Auth Method (1 octet) RESERVED (3 octets)
    Authentication Data (variable)
    1.2.4.10. Nonce Payload
    Nonce Payload Format
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) Critical (1 bit) RESERVED (7 bits) Payload Length (2 octets)
    Nonce Data (variable)
    1.2.4.11. Notify Payload
    Notify Payload Format
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) Critical (1 bit) RESERVED (7 bits) Payload Length (2 octets)
    Protocol ID (1 octet) SPI Size (1 octet) Notify Message Type (2 octets)
    Security Parameter Index (SPI, variable)
    Notification Data (variable)
    1.2.4.12. Delete Payload
    Delete Payload Format
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) Critical (1 bit) RESERVED (7 bits) Payload Length (2 octets)
    Protocol ID (1 octet) SPI Size (1 octet) Num of SPIs (2 octets)
    Security Parameter Index(es) (SPI, variable)
    1.2.4.13. Vendor ID Payload
    Vendor ID Payload Format
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) Critical (1 bit) RESERVED (7 bits) Payload Length (2 octets)
    Vendor ID (VID, variable)
    1.2.4.14. Traffic Selector Payload
    Traffic Selectors Payload Format
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) Critical (1 bit) RESERVED (7 bits) Payload Length (2 octets)
    Number of TSs (1 octet) RESERVED (3 octets)
    <Traffic Selectors> (variable)
    1.2.4.15. Encrypted Payload
    Encrypted Payload Format
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) Critical (1 bit) RESERVED (7 bits) Payload Length (2 octets)
    Initialization Vector (length is block size for encryption algorithm)
    Encrypted IKE Payloads (variable)
    Padding (0-255 octets) Pad Length (1 octet)
    Integrity Checksum Data (variable)
    1.2.4.16. Configuration Payload
    Configuration Payload Format
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) Critical (1 bit) RESERVED (7 bits) Payload Length (2 octets)
    CFG Type (1 octet) RESERVED (3 octets)
    Configuration Attributes (variable)
    1.2.4.17. Extensible Authentication Protocol (EAP) Payload
    EAP Payload Format
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Next Payload (1 octet) Critical (1 bit) RESERVED (7 bits) Payload Length (2 octets)
    EAP Message (variable)

    1.2.5. ESP ([https]RFC4303 - IP Encapsulating Security Payload[](https://www.rfc-editor.org/rfc/rfc4303))

    1.2.5.1. ESP Header Format
    ESP Header Format
    0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
    Security Parameters Index (SPI, 4 octets)
    Sequence Number (4 octets)
    Payload Data (variable)
    Padding (0-255 bytes) Pad Length Next Header
    Authentication Data (variable) 
        0                   1                   2                   3    
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1    
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               Security Parameters Index (SPI)                 |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                      Sequence Number                          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                    Payload Data (variable)                    |
    ~                                                               ~
    |                                                               |
    +               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |               |     Padding (0-255 bytes)                     |
    +-+-+-+-+-+-+-+-+               +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                               |  Pad Length   | Next Header   |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |                 Authentication Data (variable)                |
    ~                                                               ~
    |                                                               |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    • 예) IPSecVPN CHILD_SA 알고리즘이 "AES_CBC_128 / HMAC_SHA1_96" 인 경우 ESP packet 암호화 구조 (NAT-T 아닌 경우, UDP Encapsulation 하지 않는 조건) 예시
      • AES_CBC_128 는 다음과 같은 속성 값이 결정됨.
        • Encrypt 암고리즘 : AES128
          • Key size : 128 bits (Round key size : 1408 bits = (1 + rounds) * blockzie))
          • Round : 10 rounds
          • Block size : 128 bits
        • 암호 운영모드 : CBC
          • IV size : 128 bits
      • Auth 알고리즘 : HMAC_SHA1
        • hmac 알고리즘 의사 구현 예시 
          => 입력 key, message, hash function, block size, output(digest) size 를 사용하여 구함.
function hmac is
    input:
        key:        Bytes    // Array of bytes
        message:    Bytes    // Array of bytes to be hashed
        hash:       Function // The hash function to use (e.g. SHA-1)
        blockSize:  Integer  // The block size of the hash function (e.g. 64 bytes for SHA-1)
        outputSize: Integer  // The output size of the hash function (e.g. 20 bytes for SHA-1)
    // Keys longer than blockSize are shortened by hashing them
    if (length(key) > blockSize) then
        key ← hash(key) // key is outputSize bytes long
    // Keys shorter than blockSize are padded to blockSize by padding with zeros on the right
    if (length(key) < blockSize) then
        key ← Pad(key, blockSize) // Pad key with zeros to make it blockSize bytes long
    o_key_pad ← key xor [0x5c * blockSize]   // Outer padded key
    i_key_pad ← key xor [0x36 * blockSize]   // Inner padded key
    return hash(o_key_pad ∥ hash(i_key_pad ∥ message))
        • Auth size (auth full bits) : 160 bits (20 bytes)
        • Auth trunc size : 96 bits (12 bytes)
          • Trunc size 는 실제 Auth size를 그대로 붙이지 않고 잘라서 붙이는 크기를 의미
        • Association data size : 64 bits (8 bytes)
          • 이 경우에는 Association data 는 ESP Header 를 의미하므로 8 bytes 가 됩니다.
      • 평문 IPv4 + Payload 가 36 bytes 인 경우
        • 암호화할 크기 = CIPHER_BLOCK_ALIGN( <평문 크기> + <Pad:align_size> + <PadLen:1byte> + <NextHeader:1byte> ) = ALIGN16 = 36 + 10 + 1 + 1 = 48 bytes
        • 대략적 암호화된 패킷 구조 
          {NewIP-Header:20bytes} +  AssociationData({ESP-Header:8bytes} + If-ESN[{ESN-SeqHi:4bytes}]) + {IV:16bytes} + CBC_Encrypt({OriginIP-Header:20bytes}+{IP-Payload:16bytes}+{Pad:10bytes}+{PadLen:1byte}+{NextHeader:1byte}) + {ESP-Tailer:12bytes}

ESP-Tailer 에는 ESP-Header 부터 ESP-Tailer 직전까지를 HMAC-SHA1 계산하여 결과를 Auth trunc size 만큼 잘라서 붙입니다.
        • 정리하면
          • 평문 앞에 추가로 붙는 순수 header 크기는 44 bytes = 20(newip) + 8(espheader) + 16(iv)
          • 평문 위에 추가로 붙는 순수 trailer 크기는 24 bytes = 10(pad) + 1(padlen) + 1(nexthdr) + 12(authtrunc)
            • 실제 내부 구현에서는 tail room 확보를 위해서 29 bytes = 16(block align size) + 1 + 12(auth trunc size) + 1 bytes 로 계산하여 공간을 확보합니다. (이 크기는 최대 padding 을 감안한 값이므로 이를 고려하여 MTU - header size - trailer size 로 참고하여 TCP의 경우 MSS 조정을 할 수 있습니다.)
          • 암호화된 L3 패킷 크기는 104 bytes = 44(header) + 36(origin) + 24(trailer) 가 됩니다.
    1.2.5.2. [https]RFC4305 - Cryptographic Algorithm Implementation Requirements for Encapsulating Security Payload (ESP) and Authentication Header (AH)[](https://tools.ietf.org/html/rfc4305)
    • Encryption and Authentication algorithms for the IPsec Encapsulating Security Payload protocol 
      Requirement    Encryption Algorithm (notes)
-----------    --------------------
MUST           NULL (1)
MUST-          TripleDES-CBC [RFC2451]
SHOULD+        AES-CBC with 128-bit keys [RFC3602]
SHOULD         AES-CTR [RFC3686]
SHOULD NOT     DES-CBC [RFC2405] (3)

Requirement    Authentication Algorithm (notes)
-----------    ------------------------
MUST           HMAC-SHA1-96 [RFC2404]
MUST           NULL (1)
SHOULD+        AES-XCBC-MAC-96 [RFC3566]
MAY            HMAC-MD5-96 [RFC2403] (2)

    1.2.6. AH ([https]RFC4302 - IP Authentication Header[](https://tools.ietf.org/html/rfc4302))

    1.2.7. IPCOMP ([https]RFC3173 - IP Payload Compression Protocol[](https://tools.ietf.org/html/rfc3173))

    1.3. 문제해결(TroubleShooting)

    하기 열거하는 모든 내용은 해답을 제시하지는 못합니다. 모든 것은 경험에 의한 고민과 선택의 문제입니다.

    1.3.1. 프로토콜 문제

    • IPSecVPN이 대상으로 하는 암/복호화 패킷은 L3 Layer 입니다. L2이하 패킷을 암/복호화 하려면 별도의 GRE, L2TP, VXLAN등의 터널을 Capsulation할 필요할 수 있습니다.
    • IKEv1은 Multi subnet (Multiple Traffic selector) 협상을 지원하지 않습니다. 때문에 하나의 CHILD_SA에 여러개의 서브넷을 협상하는 구성은 만들 수 없습니다.
      • Cisco Unity 확장(비표준이지만 널리 알려진 확장)을 지원한다면 가능할 수 있습니다.
      • IKEv2가 사용가능하다면 IKEv1이 아닌 IKEv2로 전환하는 것도 방법일 수 있습니다.
    • 일반적으로 IKE_SA의 유효시간이 CHILD_SA유효시간보다 길게 설정하시는게 좋은거 같습니다.
    • ESP header 의 sequence number 는 32bits 이며 기본적으로는 ESN을 사용하지 않으면 overflow를 허용하지 않습니다. 높은 트래픽을 사용하는 터널 구성인 경우 이 값이 CHILD_SA 유효시간 도달하기 전에 overflow에 도달할 수 있으며 이렇게 되면 암호화 전송이 무시될 수 있습니다.
      • ESN을 사용하시는 방법
      • 32bits sequence number 가 overflow 되지 않는 충분히 짧은 CHILD_SA 유효시간으로 설정하는 방법 (10G NIC기준 최대 트래픽시 2시간이내에 도달할 수 있기 때문)
    • 하나의 터널을 구성하는 IKE와 IPSec의 연결유지를 위해서 IKE의 경우는 DPD check를 필요로 하며 IPSec의 연결유지는 별도의 암/복호화 유발하는 Checker 가 필요합니다.
      • IKE의 연결 유지는 DPD 수신 유무가 관건이며 양쪽 장비 모두에서 DPD요청설정을 할 필요는 없고 한쪽만 하면 충분합니다.
      • IPSec의 연결 유지는 수신되는 복호화 패킷의 존재 유무가 관건입니다.
    • 양쪽 장비가 모두 Initiator로 구성하게 되면 초기 터널 연결시에 다소 불완전한 연결이 될 수 있습니다.

    1.3.2. 성능 문제

    • IPSecVPN Tunnel mode 로 트래픽이 흐르는 구성일 때 터널 주소(암호화된 패킷의 출발지 및 목적지 주소)가 동일한 패킷이기 때문에 NIC Driver의 수신부에서 Core/IRQ 분산에 필요한 조건을 식별할 수 없어 특정 Core에 복호화 부하가 집중될 소지가 있습니다. 성능을 도모하기 위해서는 이에 대한 고민이 필요할 수 있습니다.
      • 터널 주소를 여러개 사용하여 구성하는 방안도 고민할 수 있어보입니다.
      • Site-to-site 구성이 꼭 필요하지 않다면 Transport mode 구성(New IP 없이 Origin IP를 그대로 사용)도 완화에 도움이 될 수 있습니다. (Site to Site를 End to End 로 각각 터널 수립)
      • Kernel의 xfrm module 에서 암/복호화 처리에 pcrypt (Parallel crypto) 를 도입해볼 수 있습니다. 이는 암/복호화 작업을 여러 Core 로 분산하여 처리할 수 있는 가능성을 열어줍니다.
      • Kernel의 RPS(Receive Packet Stearing, NIC Driver에서 결정한 IRQ분산을 재분배하기 위해서 backlog queue로 회기시키는 기능) 을 활성화하는 시도도 있을 수 있습니다.
      • Core/IRQ 분산을 도입하는 경우 패킷의 순서 보장에 대한 고민이 필요합니다.
    • 가장 빠른 암/복호화 및 Auth 알고리즘 선택의 문제
      • Intel 계열의 CPU는 AES-NI 가속 명령어를 도입해볼 수 있습니다. 즉, 보통은 AES-NI를 지원한다면 AES128GCM-GHASH8 이 가장 높은 성능을 기대할 수 있는 알고리즘이 될 가능성이 높습니다.
      • 전용 H/W 가속기 사용도 고려해볼 수 있으나 비용 측면은 물론이지만 응답성도 확인이 필요해보입니다.
    • Kernel은 비선점 커널로 빌드해서 사용해보는 것도 좋을 수 있어보입니다.

    1.3.3. 보안 문제

    • 모든 알고리즘은 Key size 가 클 수록 좋으나 성능은 떨어지므로 적절한 Key size 알고리즘을 선택하는 것이 필요.
    • IKEv1의 Aggressive mode 는 Hash값이 그대로 노출되는 이유로 가급적 Main mode를 사용하시는게 좋습니다.
    • CHILD_SA의 Diffie-Hellman group을 지정하여 PFS구성을 사용하실 것을 권고합니다.
      • IKE의 DH group 과 IPSec(CHILD_SA)의 DH group은 다른 것이며 올바른 구성이 되었다면 CHILD_SA rekey까지 올바르게 되는지 확인이 필요합니다.

    1.4. 참고자료

    1.4.1. Linux Kernel 에서의 Transform(IPSec VPN, xfrm) 흐름도 정리

    1.4.1.1. Linux Kernel v3.x 기준 Transform(IPSec VPN, xfrm) packet 흐름의 요약 정리
    Linux Kernel v3.x 기준 Transform packet 흐름 요약
    [PNG image (131.6 KB)]
    1.4.1.2. Linux Kernel v3.x 기준 Transform(IPSec VPN, xfrm) packet 흐름에서 암호화(Encrypt) 부분 요약 정리
    Linux Kernel v3.x 기준 Transform packet 암호화(Encrypt) 흐름 부분
    [PNG image (140.24 KB)]
    1.4.1.3. Linux Kernel v3.x 기준 Transform(IPSec VPN, xfrm) packet 흐름에서 복호화(Decrypt) 부분 요약 정리
    Linux Kernel v3.x 기준 Transform packet 복호화(Decrypt) 흐름 부분
    [PNG image (114.1 KB)]
    1.4.1.4. Linux Kernel v3.x 기준 Transform(IPSec VPN, xfrm) packet 흐름도 상세 정리
    Linux Kernel v3.x 기준 Transform packet 흐름도 정리
    [PNG image (557.04 KB)]
    1.4.1.5. Linux Kernel v3.x 기준 xfrm_lookup 함수 정리
    Linux Kernel v3.x 기준 xfrm_lookup 함수 정리
    [PNG image (251.51 KB)]
    1.4.1.6. Linux Kernel v5.x 에서의 XDP 및 xfrm(IPSec) 흐름 요약
    Linux Kernel v5.x 에서의 XDP 및 xfrm(IPSec) 흐름 요약
    [PNG image (443.03 KB)]

    1.4.2. 용어정의

    1.4.3. 관련 표준안

    1.4.4. 표준안 관련 도움글

    1.4.5. 내부 관련 글

    1.4.6. 관련 글

    1.4.7. 관련 참고할만한 자체 공개프로젝트

    • HWPORT PGL(Porting Glue Layer) SDK : H/W 및 OS에 구애받지 않고 일관된 API로 구현할수 있도록 해주는 SDK library
    • HWPORT FTP Server : FTP Server 구현을 Library 형태로 제한적인 제공을 하는 library
    • HWPORT stealth portscan : TCP port에 대한 stealth scan 을 구현한 예제
    • hwport_aes : AES 암호화/부호화 library (ECB, CFB8, OFB8)
    • mzproxy : 단순히 TCP port forwarding 정도의 기능과 간략한 약식 구현수준의 telnet server 기능을 구현한 proxy server
    • mzping (ICMPv4/ICMPv6) : ICMP에 대한 예제 (IPv4, IPv6 지원)
    • mzcrc : CRC 16/32/64 를 표준에 입각하여 구현한 library
    • mzdes : DES/3DES 암호화/부호화 library (ECB)
    • mzseed : SEED 암호화/부호화 library (ECB)
    • mzmd5 : MD5 digest library (HASH)
    • mzpwcrack : Linux password cracker 예제
    • mzslab : 슬랩할당자 (Slab Allocator) library 및 예제

    1.4.8. 관련 주요 공개프로젝트

    1.4.9. 관련 서적

    • "네트워크 보안 프로토콜" - ([http]도서정보 관련링크[](http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788909098830&orderClick=LAG&Kc=))
      • [ISBN-890909883X]
    • "안전한 VPN을 위한 인터넷 보안 프로토콜" - ([http]도서정보 관련링크[](http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788995324325&orderClick=LAH&Kc=))
      • [ISBN-8995324325]
    • "VPN 가상사설망 완전정복" - ([http]도서정보 관련링크[](http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788997030064&orderClick=LAH&Kc=))
    • "리눅스 네트워크의 이해" - ([http]도서정보 관련링크[](http://www.kyobobook.co.kr/product/detailViewKor.laf?ejkGb=KOR&mallGb=KOR&barcode=9788960778719&orderClick=LAH&Kc=))
    Retrieved from https://www.minzkn.com:443/moniwiki/wiki.php/VirtualPrivateNetwork
    last modified 2024-05-17 23:26:16