1.1. 개요


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

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

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.3. VPN의 요소


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

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

필요한 주요기술적 관점은 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[] VPN (Generic) IPSec VPN Layer 3 이상 본사와 지사간 연결 보통 대규모 VPN에 많이 사용되며 가장 기본적인 VPN이라고 할 수 있습니다.
[https]GRE(Generic Routing Encapsulation)[] IPSec VPN Layer 3 이상 본사와 지사간 연결 [https]GRE(Generic Routing Encapsulation)[]를 이용하여 Routing을 해결하는 IPSec VPN
[https]Dynamic Multipoint VPN (DMVPN)[] 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[] VPN Layer 5 이상 서버와 PC 연결 전자상거래등의 용도로 많이 사용하며 다양한 정책들을 수립하기 좋습니다.
[https]PPTP[] VPN Layer 2 이상 본사와 PC 연결 외부근무자에게 내부망으로의 접속을 허용하기 위해서 많이 사용합니다.
[https]L2TP[] VPN Layer 2 이상 본사와 PC 연결 외부근무자에게 내부망으로의 접속을 허용하기 위해서 많이 사용하지만 요즘에는 비교적 많이 쓰이지는 않습니다.
[https]MPLS[] VPN 암호화 하지 않음 본사와 지사간 연결 보통은 ISP측에서 제공하므로 사용자 입장에서는 별도의 장비구입이 필요없는 경우가 대부분이며, IPSec VPN과 함께 사용합니다.

1.2. IPSec VPN


1.2.2. 구성요소


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

1.2.3. ISAKMP (Internet Security Association and Key Management Protocol)


  • [https]RFC2408 - Internet Security Association and Key Management Protocol[] 는 통신하고자 하는 양단간에 통신을 보호하기 위한 보안통신을 달성하기 위해서 필요한 암호화 및 무결성 확인을 방법이 정해지도록 일련의 절차들이 필요한데 이와 같은 일을 하도록 절차를 명시한 Protocol 이라고 할 수 있습니다.
  • 이와 혼용해서 많이 표현되는 것중에 [https]RFC2409 - The Internet Key Exchange[] 가 있으며 이것은 ISAKMP가 명시한 절차에 필요한 구체적인 Protocol의 종류와 사용방법등을 정의한 것입니다. 그러나 이 둘간의 유사성이 매우 커서 2010년 9월에 개정된 [https]RFC5996 - Internet Key Exchange Protocol Version 2[] 에서 IKE와 ISAKMP를 통합하여 정의하게 되었습니다.
  • 보안을 만족하는 통신을 위해서 필요한 일련의 Protocol, Algorithm, Key, 그외의 속성들을 [https]SA(Securify 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)[]기능을 제공해야 하며 이를 위해서 다음을 만족하도록 정의됩니다.

  • 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)[] 에 대한 취약성에 유의해야 합니다.

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)[] 를 생성하여 교환하는 과정이며 단계2(Phase 2)의 협상(Negotiation)할 때의 정보들을 암호화 하는데 사용됩니다.
    • 쌍방간의 IKE SA(Security Association)가 설정됩니다.
      • 인증에 필요한 요소들 (Authentication method)
        • Ex) pre-shared key, RSA signature, …
      • 양단(End-point)간의 유효성을 확인하기 위한 요소들 (Hash algorithm)
        • Ex) MD5, SHA1, …
      • 암호/복호에 사용될 알고리즘 요소들 (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)[]는 안전하게 보호될 수 있으며 이를 이용하여 실제 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)[]를 달성합니다.
    • IPSec SA의 유효시간(Life time) 과 유효크기(life size) 결정

    1.2.3.9. [https]SA (Security Association, 보안 관련 집합정보)[] 요소

    • SPI (Security Parameter Index, 32-bits) (참고: [https]RFC4303 - Section 2.1. Security Parameters Index[])
      • SA를 검색 및 식별하기 위해서 각 보안 프로토콜들은 SPI를 나타내는 영역을 가지고 있으며 이는 시스템 내에서 유일한 값으로 사용합니다.
    • DOI (Domain of Interpretation) (참고: [https]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[])
      • 협상에 필요한 보안 서비스를 결정하기 위해서 필요한 모든 정보를 말합니다.
    • Exchange Type
      • 메세지의 수와 Payload들이 정의되며 익명성, [https]PFS(Perfect Forward Secrecy)[], 인증등의 서비스를 달성하기 위해서 메세지의 교환 형태가 정의된 것을 말합니다.
    • Payload
    • 제안 및 협상 (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[])
    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[])
      2 Proposal (P, [https]RFC2408[])
      3 Transform (T, [https]RFC2408[])
      4 Key Exchange (KE, [https]RFC2408[])
      5 Identification (ID: IDi/IDr, [https]RFC2408[])
      6 Certification (CERT, [https]RFC2408[])
      7 Cerificate Request (CR, [https]RFC2408[])
      8 Hash (HASH) (AUTH, [https]RFC2408[])
      9 Signature (SIG, [https]RFC2408[])
      10 Nonce (NONCE, [https]RFC2408[])
      11 Notification (N, [https]RFC2408[])
      12 Delete (D, [https]RFC2408[])
      13 Vendor (VID, [https]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]RFC6407[])
      16 SA TEK Payload (SAT, [https]RFC3547[], [https]RFC6407[])
      17 Key Download (KD, [https]RFC3547[])
      18 Sequence Number (SEQ, [https]RFC3547[])
      19 Proof of Possession (POP, [https]RFC3547[])
      20 NAT Discovery (NAT-D, [https]RFC3947[])
      21 NAT Original Address (NAT-OA, [https]RFC3947[])
      22~32 RESERVED
      33 Security Association (SA, [https]RFC7296[])
      34 Key Exchange (KE, [https]RFC7296[])
      35 Identification - Initiator (IDi, [https]RFC7296[])
      36 Identification - Responder (IDr, [https]RFC7296[])
      37 Certificate (CERT, [https]RFC7296[])
      38 Certificate Request (CERTREQ, [https]RFC7296[])
      39 Authentication (AUTH, [https]RFC7296[])
      40 Nonce (Ni/Nr, [https]RFC7296[])
      41 Notify (N, [https]RFC7296[])
      42 Delete (D, [https]RFC7296[])
      43 Vendor ID (V, [https]RFC7296[])
      44 Traffic Selector - Initiator (TSi, [https]RFC7296[])
      45 Traffic Selector - Responder (TSr, [https]RFC7296[])
      46 Encrypted and Authenticated (SK, [https]RFC7296[])
      47 Configuration (CP, [https]RFC7296[])
      48 Extensible Authentication (EAP, [https]RFC7296[])
      49 Generic Secure Password Method (GSPM, [https]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[])
      54 Puzzle Solution (PS, [https]RFC8019[])
      55~127 RESERVED
      128~255 Private Use
    • Major / Minor version field
    • "Exchange Type" : Message의 교환 유형를 나타냅니다.
      Exchange Type
      IKEv1
      의미
      0 None ([https]RFC2408[])
      1 Base ([https]RFC2408[])
      2 Identify Protection ([https]RFC2408[])
      3 Authentication Only ([https]RFC2408[])
      4 Aggressive ([https]RFC2408[])
      5 Informational ([https]RFC2408[])
      6~31 ISAKMP Future Use
      32 Quick Mode ([https]RFC2409[])
      33 New Group Mode ([https]RFC2409[])
      34 IKE_SA_INIT ([https]RFC7296[])
      35 IKE_AUTH ([https]RFC7296[])
      36 CREATE_CHILD_SA ([https]RFC7296[])
      37 INFORMATIONAL ([https]RFC7296[])
      38 IKE_SESSION_RESUME ([https]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[])
    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[])
    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[])
    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[])를 지칭합니다.
      • 그 밖에 나머지는 IANA에서 미래를 위해서 예약된 값이며 RFC와 같은 사양을 연계참조하지 않고 임의로 값을 할당하지는 않습니다.
    • "Situation" : DOI에서 지정한 필드규격에 맞게 가변길이로 표현됩니다. (참고: [https]RFC2407 Section 4.6.1 Security Association Payload[])

    1.3. 참고자료


    1.3.1. 용어정의


    1.3.2. 관련 표준안


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


    • 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.3.8. 관련 서적


    


    /*
    [ FrontPage | PrintView | RawView | RSS ]

    Copyright ⓒ MINZKN.COM
    All Rights Reserved.

    MINZKN
    */