IKE Phase 2 (Internet Key Exchange Phase 2)
1. 개요
IKE Phase 2는 IPsec(Internet Protocol Security) 통신을 위해 실제 사용자 데이터(User Data)를 암호화하여 전송할 보안 연결인 IPsec SA(Security Association)를 생성하고 관리하는 단계이다.
IKE Phase 1이 두 게이트웨이 간의 안전한 관리 채널(IKE SA)을 구축하는 것이 목적이라면, Phase 2는 이 안전한 채널 내부에서 실제 트래픽을 보호하기 위한 구체적인 암호화 키와 정책을 협상하는 역할을 수행한다. 즉, Phase 1이 '신뢰할 수 있는 통로'를 만드는 과정이라면, Phase 2는 그 통로를 통해 '실제 데이터를 어떻게 주고받을지' 결정하는 과정이다.
2. 동작 원리 및 프로세스
IKE Phase 2는 Phase 1에서 이미 구축된 보안 채널을 통해 수행되므로, 메시지 자체가 암호화되어 전송된다. 이 단계의 핵심은 IPsec SA를 생성하는 것이다. SA란 통신 양단이 합의한 보안 파라미터의 집합으로, 어떤 알고리즘을 사용할지, 키는 무엇인지 등을 정의한 일종의 '계약서'와 같다.
Phase 1 vs Phase 2 비교
| 구분 |
IKE Phase 1 |
IKE Phase 2 |
| 주요 목적 |
관리 채널(IKE SA) 구축 및 상호 인증 |
데이터 전송 채널(IPsec SA) 구축 |
| 보안 대상 |
IKE 제어 메시지 자체를 보호 |
실제 사용자 데이터(Payload)를 보호 |
| 결과물 |
IKE SA (양방향 1개) |
IPsec SA (단방향 2개 - Inbound/Outbound) |
| 실행 횟수 |
터널당 최초 1회 (재협상 전까지) |
트래픽 종류/정책별로 여러 번 생성 가능 |
3. 주요 협상 요소
Phase 2 협상 과정에서는 데이터 패킷을 어떻게 처리할지에 대한 Security Parameter Index(SPI)와 세부 파라미터를 결정한다.
3.1 핵심 파라미터
- 보안 프로토콜 (Security Protocol): 사용할 프로토콜을 결정한다.
- ESP (Encapsulating Security Payload): 암호화와 인증을 모두 제공하며, 현대 VPN의 대부분이 사용한다.
- AH (Authentication Header): 인증과 무결성만 제공하며, 데이터 암호화는 수행하지 않는다.
- 암호화 알고리즘 (Encryption Algorithm): 데이터 기밀성을 보장하기 위한 알고리즘 (예: AES-256, 3DES).
- 인증 알고리즘 (Authentication Algorithm): 데이터 무결성과 송신처 확인을 위한 해시 함수 (예: SHA-256, HMAC-SHA1).
-
캡슐화 모드 (Encapsulation Mode):
- Transport Mode: IP 헤더는 유지하고 페이로드만 암호화. 주로 호스트 간 통신에 사용.
- Tunnel Mode: 원래의 IP 패킷 전체를 암호화하고 새로운 IP 헤더를 추가. 주로 게이트웨이 간(Site-to-Site) VPN에 사용.
[모드 비교 시각화]
- Transport Mode: [Original IP Header] [ESP/AH Header] [Payload (Encrypted)] [ESP Trailer]
- Tunnel Mode: [New IP Header] [ESP/AH Header] [Original IP Header (Encrypted)] [Payload (Encrypted)] [ESP Trailer]
-
SPI (Security Parameter Index): 수신 측에서 여러 개의 SA 중 어떤 SA를 적용해 복호화해야 하는지 식별하기 위해 패킷 헤더에 포함되는 고유 식별자.
- 처리 흐름:
수신 패킷 헤더 $\rightarrow$ [SPI 값 추출] $\rightarrow$ SA 데이터베이스(SAD) 조회 $\rightarrow$ 매칭되는 키/알고리즘 적용 $\rightarrow$ 복호화
3.2 트래픽 셀렉터 (Traffic Selector / Proxy-ID)
트래픽 셀렉터는 어떤 트래픽이 이 IPsec 터널을 통해 전송될지를 정의하는 범위이다. 보통 로컬 서브넷과 원격 서브넷의 IP 대역, 프로토콜, 포트 번호로 구성된다.
* 개념: "A 네트워크(10.1.1.0/24)에서 B 네트워크(192.168.1.0/24)로 가는 UDP 500번 포트 트래픽만 이 SA를 사용한다"라고 정의하는 것.
* 주의사항: 양단 게이트웨이의 트래픽 셀렉터 설정이 정확히 대칭(Mirror)되지 않으면 Phase 2 협상이 실패한다.
4.1 Quick Mode (IKEv1)
IKEv1에서 Phase 2는 Quick Mode라는 메커니즘을 통해 동작한다. Phase 1에서 생성된 키를 사용하여 빠르게 SA를 생성하므로 'Quick'이라는 명칭이 붙었다. 별도의 인증 과정을 생략하고 Phase 1의 보안 컨텍스트를 재사용하여 효율성을 높였다.
4.2 IKEv1 vs IKEv2 비교
IKEv2에서는 Phase 1과 Phase 2의 구분이 모호해졌으며, IKE_SA_INIT와 IKE_AUTH 이후 CREATE_CHILD_SA 메시지를 통해 IPsec SA를 생성한다. 특히 IKEv2에서는 Phase 2 SA라는 용어 대신 Child SA라는 용어를 사용하며, 이는 IKE SA에 종속된 형태로 생성되어 IKEv1의 Phase 2 SA와 기능적으로 동일한 역할을 수행한다.
[IKEv2 CREATE_CHILD_SA 흐름]
IKE SA (기존 연결) $\rightarrow$ CREATE_CHILD_SA 요청 (신규 SA 파라미터 제안) $\rightarrow$ CREATE_CHILD_SA 응답 (합의 및 키 생성) $\rightarrow$ Child SA (IPsec SA) 생성 완료
| 항목 |
IKEv1 (Phase 2) |
IKEv2 (Child SA) |
| 메커니즘 |
Quick Mode |
CREATE_CHILD_SA |
| 메시지 교환 |
3-way handshake |
2-way exchange (더 빠름) |
| 유연성 |
설정이 경직적이며 복잡함 |
트래픽 셀렉터 협상이 유연함 |
| 신뢰성 |
연결 끊김 감지가 느림 |
Liveness Check (Keep-alive) 내장 |
5. PFS (Perfect Forward Secrecy)
PFS(완전 순방향 비밀성)는 Phase 2 SA를 생성할 때 Phase 1에서 사용한 키를 재사용하지 않고, Diffie-Hellman(DH) 키 교환을 다시 수행하여 완전히 새로운 키를 생성하는 기능이다.
- 필요성: 만약 PFS를 사용하지 않으면, Phase 1의 마스터 키가 탈취되었을 때 이를 통해 생성된 모든 Phase 2 세션 키가 한꺼번에 노출될 위험이 있다.
- 원리: Phase 2 협상 시점에 새로운 DH 공유 비밀값을 생성함으로써, 과거의 키가 유출되더라도 현재 및 미래의 세션 키는 안전하게 보호한다.
- 트레이드-오프: 매번 DH 연산을 수행하므로 CPU 부하가 증가하며 협상 시간이 약간 길어진다.
6. SA 생명주기(Lifetime) 및 재협상
IPsec SA는 보안을 위해 무한정 유지되지 않으며, 설정된 Lifetime이 만료되면 삭제되고 재협상된다.
- 시간 기반 만료 (Time-based): 설정된 시간(예: 3,600초)이 지나면 SA를 폐기한다.
- 데이터 기반 만료 (Volume-based): 전송된 데이터 양(예: 4GB)이 임계치에 도달하면 SA를 폐기한다.
- 재협상 (Rekeying): SA가 완전히 만료되어 통신이 끊기기 전, 보통 Lifetime의 80~90% 시점에 새로운 SA를 미리 협상하는 'Soft Lifetime' 과정을 거쳐 끊김 없는(Seamless) 전환을 수행한다.
- SA 삭제: 새로운 SA가 성공적으로 생성되면 기존의 만료된 SA는 즉시 또는 짧은 유예 기간 후 삭제되어 자원을 회수한다.
7. 트러블슈팅 및 설정 예시
7.1 주요 실패 원인
Phase 2 협상 실패(Phase 2 Down) 시 가장 빈번한 원인은 다음과 같다.
* Proposal 불일치: 암호화 알고리즘(AES vs 3DES)이나 해시 알고리즘(SHA256 vs SHA1)이 양단에서 서로 다를 때.
* Proxy-ID(트래픽 셀렉터) 불일치: 로컬/원격 네트워크 대역 설정이 서로 대칭되지 않을 때.
* PFS 설정 불일치: 한쪽은 PFS를 사용하도록 설정하고, 다른 쪽은 사용하지 않을 때.
7.2 설정 예시 (Cisco IOS CLI)
아래는 Phase 2(IPsec Transform-set 및 Crypto Map) 설정의 예시이다.
! 1. Transform-set 정의 (암호화 및 인증 알고리즘 결정)
crypto ipsec transform-set MY-SET esp-aes 256 esp-sha256-hmac
mode tunnel
! 2. ACL 정의 (트래픽 셀렉터/Proxy-ID 설정)
access-list 101 permit ip 10.1.1.0 0.0.0.255 192.168.1.0 0.0.0.255
! 3. Crypto Map 생성 및 결합
crypto map MY-MAP 10 ipsec-isakmp
set peer 203.0.113.1
set transform-set MY-SET
match address 101
! PFS 설정 (DH Group 14 사용)
set pfs group14
# IKE Phase 2 (Internet Key Exchange Phase 2)
## 1. 개요
**IKE Phase 2**는 IPsec(Internet Protocol Security) 통신을 위해 실제 사용자 데이터(User Data)를 암호화하여 전송할 보안 연결인 **IPsec SA(Security Association)**를 생성하고 관리하는 단계이다.
IKE Phase 1이 두 게이트웨이 간의 안전한 관리 채널(IKE SA)을 구축하는 것이 목적이라면, Phase 2는 이 안전한 채널 내부에서 실제 트래픽을 보호하기 위한 구체적인 암호화 키와 정책을 협상하는 역할을 수행한다. 즉, Phase 1이 '신뢰할 수 있는 통로'를 만드는 과정이라면, Phase 2는 그 통로를 통해 '실제 데이터를 어떻게 주고받을지' 결정하는 과정이다.
## 2. 동작 원리 및 프로세스
IKE Phase 2는 Phase 1에서 이미 구축된 보안 채널을 통해 수행되므로, 메시지 자체가 암호화되어 전송된다. 이 단계의 핵심은 **IPsec SA**를 생성하는 것이다. SA란 통신 양단이 합의한 보안 파라미터의 집합으로, 어떤 알고리즘을 사용할지, 키는 무엇인지 등을 정의한 일종의 '계약서'와 같다.
### Phase 1 vs Phase 2 비교
| 구분 | IKE Phase 1 | IKE Phase 2 |
| :--- | :--- | :--- |
| **주요 목적** | 관리 채널(IKE SA) 구축 및 상호 인증 | 데이터 전송 채널(IPsec SA) 구축 |
| **보안 대상** | IKE 제어 메시지 자체를 보호 | 실제 사용자 데이터(Payload)를 보호 |
| **결과물** | IKE SA (양방향 1개) | IPsec SA (단방향 2개 - Inbound/Outbound) |
| **실행 횟수** | 터널당 최초 1회 (재협상 전까지) | 트래픽 종류/정책별로 여러 번 생성 가능 |
## 3. 주요 협상 요소
Phase 2 협상 과정에서는 데이터 패킷을 어떻게 처리할지에 대한 **Security Parameter Index(SPI)**와 세부 파라미터를 결정한다.
### 3.1 핵심 파라미터
* **보안 프로토콜 (Security Protocol):** 사용할 프로토콜을 결정한다.
* **ESP (Encapsulating Security Payload):** 암호화와 인증을 모두 제공하며, 현대 VPN의 대부분이 사용한다.
* **AH (Authentication Header):** 인증과 무결성만 제공하며, 데이터 암호화는 수행하지 않는다.
* **암호화 알고리즘 (Encryption Algorithm):** 데이터 기밀성을 보장하기 위한 알고리즘 (예: AES-256, 3DES).
* **인증 알고리즘 (Authentication Algorithm):** 데이터 무결성과 송신처 확인을 위한 해시 함수 (예: SHA-256, HMAC-SHA1).
* **캡슐화 모드 (Encapsulation Mode):**
* **Transport Mode:** IP 헤더는 유지하고 페이로드만 암호화. 주로 호스트 간 통신에 사용.
* **Tunnel Mode:** 원래의 IP 패킷 전체를 암호화하고 새로운 IP 헤더를 추가. 주로 게이트웨이 간(Site-to-Site) VPN에 사용.
**[모드 비교 시각화]**
- **Transport Mode:** `[Original IP Header] [ESP/AH Header] [Payload (Encrypted)] [ESP Trailer]`
- **Tunnel Mode:** `[New IP Header] [ESP/AH Header] [Original IP Header (Encrypted)] [Payload (Encrypted)] [ESP Trailer]`
* **SPI (Security Parameter Index):** 수신 측에서 여러 개의 SA 중 어떤 SA를 적용해 복호화해야 하는지 식별하기 위해 패킷 헤더에 포함되는 고유 식별자.
- **처리 흐름:** `수신 패킷 헤더` $\rightarrow$ `[SPI 값 추출]` $\rightarrow$ `SA 데이터베이스(SAD) 조회` $\rightarrow$ `매칭되는 키/알고리즘 적용` $\rightarrow$ `복호화`
### 3.2 트래픽 셀렉터 (Traffic Selector / Proxy-ID)
트래픽 셀렉터는 어떤 트래픽이 이 IPsec 터널을 통해 전송될지를 정의하는 범위이다. 보통 **로컬 서브넷**과 **원격 서브넷**의 IP 대역, 프로토콜, 포트 번호로 구성된다.
* **개념:** "A 네트워크(10.1.1.0/24)에서 B 네트워크(192.168.1.0/24)로 가는 UDP 500번 포트 트래픽만 이 SA를 사용한다"라고 정의하는 것.
* **주의사항:** 양단 게이트웨이의 트래픽 셀렉터 설정이 정확히 대칭(Mirror)되지 않으면 Phase 2 협상이 실패한다.
## 4. Quick Mode 및 IKE 버전별 차이
### 4.1 Quick Mode (IKEv1)
IKEv1에서 Phase 2는 **Quick Mode**라는 메커니즘을 통해 동작한다. Phase 1에서 생성된 키를 사용하여 빠르게 SA를 생성하므로 'Quick'이라는 명칭이 붙었다. 별도의 인증 과정을 생략하고 Phase 1의 보안 컨텍스트를 재사용하여 효율성을 높였다.
### 4.2 IKEv1 vs IKEv2 비교
IKEv2에서는 Phase 1과 Phase 2의 구분이 모호해졌으며, `IKE_SA_INIT`와 `IKE_AUTH` 이후 `CREATE_CHILD_SA` 메시지를 통해 IPsec SA를 생성한다. 특히 IKEv2에서는 Phase 2 SA라는 용어 대신 **Child SA**라는 용어를 사용하며, 이는 IKE SA에 종속된 형태로 생성되어 IKEv1의 Phase 2 SA와 기능적으로 동일한 역할을 수행한다.
**[IKEv2 CREATE_CHILD_SA 흐름]**
`IKE SA (기존 연결)` $\rightarrow$ `CREATE_CHILD_SA 요청 (신규 SA 파라미터 제안)` $\rightarrow$ `CREATE_CHILD_SA 응답 (합의 및 키 생성)` $\rightarrow$ `Child SA (IPsec SA) 생성 완료`
| 항목 | IKEv1 (Phase 2) | IKEv2 (Child SA) |
| :--- | :--- | :--- |
| **메커니즘** | Quick Mode | CREATE_CHILD_SA |
| **메시지 교환** | 3-way handshake | 2-way exchange (더 빠름) |
| **유연성** | 설정이 경직적이며 복잡함 | 트래픽 셀렉터 협상이 유연함 |
| **신뢰성** | 연결 끊김 감지가 느림 | Liveness Check (Keep-alive) 내장 |
## 5. PFS (Perfect Forward Secrecy)
**PFS(완전 순방향 비밀성)**는 Phase 2 SA를 생성할 때 Phase 1에서 사용한 키를 재사용하지 않고, **Diffie-Hellman(DH) 키 교환**을 다시 수행하여 완전히 새로운 키를 생성하는 기능이다.
* **필요성:** 만약 PFS를 사용하지 않으면, Phase 1의 마스터 키가 탈취되었을 때 이를 통해 생성된 모든 Phase 2 세션 키가 한꺼번에 노출될 위험이 있다.
* **원리:** Phase 2 협상 시점에 새로운 DH 공유 비밀값을 생성함으로써, 과거의 키가 유출되더라도 현재 및 미래의 세션 키는 안전하게 보호한다.
* **트레이드-오프:** 매번 DH 연산을 수행하므로 CPU 부하가 증가하며 협상 시간이 약간 길어진다.
## 6. SA 생명주기(Lifetime) 및 재협상
IPsec SA는 보안을 위해 무한정 유지되지 않으며, 설정된 **Lifetime**이 만료되면 삭제되고 재협상된다.
1. **시간 기반 만료 (Time-based):** 설정된 시간(예: 3,600초)이 지나면 SA를 폐기한다.
2. **데이터 기반 만료 (Volume-based):** 전송된 데이터 양(예: 4GB)이 임계치에 도달하면 SA를 폐기한다.
3. **재협상 (Rekeying):** SA가 완전히 만료되어 통신이 끊기기 전, 보통 Lifetime의 80~90% 시점에 새로운 SA를 미리 협상하는 'Soft Lifetime' 과정을 거쳐 끊김 없는(Seamless) 전환을 수행한다.
4. **SA 삭제:** 새로운 SA가 성공적으로 생성되면 기존의 만료된 SA는 즉시 또는 짧은 유예 기간 후 삭제되어 자원을 회수한다.
## 7. 트러블슈팅 및 설정 예시
### 7.1 주요 실패 원인
Phase 2 협상 실패(Phase 2 Down) 시 가장 빈번한 원인은 다음과 같다.
* **Proposal 불일치:** 암호화 알고리즘(AES vs 3DES)이나 해시 알고리즘(SHA256 vs SHA1)이 양단에서 서로 다를 때.
* **Proxy-ID(트래픽 셀렉터) 불일치:** 로컬/원격 네트워크 대역 설정이 서로 대칭되지 않을 때.
* **PFS 설정 불일치:** 한쪽은 PFS를 사용하도록 설정하고, 다른 쪽은 사용하지 않을 때.
### 7.2 설정 예시 (Cisco IOS CLI)
아래는 Phase 2(IPsec Transform-set 및 Crypto Map) 설정의 예시이다.
```bash
! 1. Transform-set 정의 (암호화 및 인증 알고리즘 결정)
crypto ipsec transform-set MY-SET esp-aes 256 esp-sha256-hmac
mode tunnel
! 2. ACL 정의 (트래픽 셀렉터/Proxy-ID 설정)
access-list 101 permit ip 10.1.1.0 0.0.0.255 192.168.1.0 0.0.0.255
! 3. Crypto Map 생성 및 결합
crypto map MY-MAP 10 ipsec-isakmp
set peer 203.0.113.1
set transform-set MY-SET
match address 101
! PFS 설정 (DH Group 14 사용)
set pfs group14
```