IPsec IKEv1 프로토콜의 이해

소개

이 문서에서는 VPN(Virtual Private Network) 설정을 위한 IKEv1(Internet Key Exchange) 프로토콜 프로세스에 대해 설명합니다.

사전 요구 사항

요구 사항

기본 보안 개념에 대한 지식을 보유하고 있는 것이 좋습니다.

• 인증
• 기밀 보장
• <Z2>신뢰</Z1><Z4>성</Z3>
• IPSec

사용되는 구성 요소

이 문서는 특정 소프트웨어 및 하드웨어 버전으로 한정되지 않습니다.

이 문서의 정보는 특정 랩 환경의 디바이스를 토대로 작성되었습니다. 이 문서에 사용된 모든 디바이스는 초기화된(기본) 컨피그레이션으로 시작되었습니다. 현재 네트워크가 작동 중인 경우 모든 명령의 잠재적인 영향을 미리 숙지하시기 바랍니다.

배경 정보

VPN(Virtual Private Network) 설정을 위한 IKEv1(Internet Key Exchange) 프로토콜 프로세스는 IKEv1과 관련된 모든 종류의 IPsec(Internet Protocol Security) 문제를 더 간단하게 해결하기 위해 패킷 교환을 이해하는 데 중요합니다.

IPSec

IPsec은 IP 레이어에서 인터넷 통신에 대한 보안을 제공하는 프로토콜 모음입니다. 현재 IPsec의 가장 일반적인 용도는 두 위치(게이트웨이 대 게이트웨이) 또는 원격 사용자와 엔터프라이즈 네트워크 (호스트 대 게이트웨이) 사이에 VPN(Virtual Private Network)을 제공하는 것입니다.

IKE 프로토콜

IPsec은 IKE 프로토콜을 사용하여 보안 사이트 대 사이트 또는 원격 액세스 VPN(Virtual Private Network) 터널을 협상하고 설정합니다. IKE 프로토콜은 ISAKMP(Internet Security Association and Key Management Protocol)라고도 합니다(시스코에서만).

IKE에는 두 가지 버전이 있습니다.

• IKEv1: RFC 2409에 정의됨, 인터넷 키 교환
• IKE 버전 2(IKEv2): RFC 4306, IKEv2(Internet Key Exchange) 프로토콜에 정의됨

IKE 단계

ISAKMP는 두 단계로 협상을 분리합니다.

• 1단계: 두 ISAKMP 피어는 ISAKMP 협상 메시지를 보호하는 안전하고 인증된 터널을 설정합니다. 이 터널을 ISAKMP SA라고 합니다. ISAKMP에 의해 정의되는 두 가지 모드, 즉 주 모드(MM)와 적극적인 모드가 있습니다.
• 2단계: IPsec 터널을 통해 전송할 데이터의 암호화(SA)에 대한 주요 자료와 알고리즘을 협상합니다. 이 단계를 빠른 모드라고 합니다.

모든 추상적인 개념을 구체화하기 위해 1단계 터널은 상위 터널이고 2단계는 하위 터널입니다. 이 그림에서는 두 단계를 터널로 설명합니다.

참고: 1단계(ISAKMP) 터널은 두 게이트웨이 간의 Control Plante VPN 트래픽을 보호합니다. 컨트롤 플레인 트래픽은 협상 패킷, 정보 패키지, DPD, 킵얼라이브, 키 재설정 등이 될 수 있습니다. ISAKMP 협상에서는 UDP 500 및 4500 포트를 사용하여 보안 채널을 설정합니다.

참고: 2단계(IPsec) 터널은 두 게이트웨이 간의 VPN을 통과하는 데이터 플레인 트래픽을 보호합니다. 데이터를 보호하는 데 사용하는 알고리즘은 2단계에서 설정하며 1단계에서 지정한 것과는 별개입니다.
이러한 패킷을 캡슐화하고 암호화하는 데 사용되는 프로토콜은 ESP(Encapsulation Security Payload)입니다.

IKE 모드(1단계)

기본 모드

IKE 세션은 이니시에이터가 응답자에 제안서를 보낼 때 시작됩니다. 노드 간의 첫 번째 교환은 기본 보안 정책을 설정합니다. 개시자는 사용할 암호화 및 인증 알고리즘을 제안합니다. 응답자는 적절한 제안을 선택하고(제안을 선택한 경우) 이를 개시자에게 보냅니다. 다음 교환은 Diffie-Hellman 공개 키 및 기타 데이터를 전달합니다. 모든 추가 협상은 IKE SA 내에서 암호화됩니다. 세 번째 교환은 ISAKMP 세션을 인증합니다. IKE SA가 설정되면 IPSec 협상(빠른 모드)이 시작됩니다.

적극적인 모드

적극적인 모드는 IKE SA 협상을 3개의 패킷으로 압축하며, SA에 필요한 모든 데이터가 이니시에이터에 의해 전달됩니다. 응답자는 제안서, 키 자료, ID를 전송하고 다음 패킷에서 세션을 인증합니다. 이니시에이터가 세션에 응답하고 인증합니다. 협상이 더 빠르며, 이니시에이터 및 응답자 ID는 일반 상태로 전달됩니다.

IPsec 모드(2단계)

빠른 모드

IPSec 협상 또는 빠른 모드는 IKE SA 내에서 보호해야 하는 협상을 제외하고 적극적인 모드 IKE 협상과 유사합니다. 빠른 모드는 데이터 암호화를 위해 SA를 협상하고 해당 IPSec SA에 대한 키 교환을 관리합니다.

IKE 용어집

• SA(Security Association)는 두 네트워크 엔티티 간 공유 보안 특성을 설정하여 보안 통신을 지원합니다. SA에는 암호화 알고리즘 및 모드, 트래픽 암호화 키, 연결을 통해 전달될 네트워크 데이터에 대한 매개변수 등의 특성이 포함됩니다.
• VID(공급업체 ID)는 피어가 NAT-Traversal, Dead Peer Detection 기능, 프래그먼트화 등을 지원하는지 여부를 확인하기 위해 처리됩니다.
• Nonce: 개시자가 전송하는 무작위로 생성된 번호입니다. 이 임시 번호는 합의된 키를 사용하여 다른 항목과 함께 해시되고 다시 전송됩니다. 이니시에이터는 쿠키와 임시 번호를 확인하고 올바른 임시 번호가 없는 메시지를 거부합니다. 이는 서드파티가 임의로 생성된 임시 번호를 예측할 수 없으므로 재생을 방지하는 데 도움이 됩니다.
• KE(키 교환): DH(Diffie-Hellman) 보안 키 교환 프로세스에 대한 정보입니다.
• IDi/IDr(ID 이니시에이터/응답자): 인증 정보를 피어로 전송하는 데 사용됩니다. 이 정보는 공통 공유 암호의 보호 하에 전송됩니다.
• DH(Diffie–Hellman) 키 교환: 공개 채널을 통해 안전하게 암호화 알고리즘을 교환하는 방법입니다.
  
• IPSec 공유 키는 PFS(Perfect Forward Secrecy) 또는 원래 DH 교환이 이전에 파생된 공유 암호로 새로 고침되도록 하기 위해 다시 DH를 사용하여 파생할 수 있습니다.

기본 모드 패킷 교환

각 ISAKMP 패킷에는 터널 설정에 대한 페이로드 정보가 포함되어 있습니다. IKE 용어집에서는 이 이미지에 표시된 대로 기본 모드에서 패킷 교환에 대한 페이로드 콘텐츠의 일부로 IKE 약어를 설명합니다.

기본 모드 1(MM1)

ISAKMP 협상 조건을 설정하려면 ISAKMP 정책을 생성하며 다음 사항이 포함됩니다.

• 피어의 ID를 확인할 인증 방법
• 데이터 및 개인정보를 보호할 암호화 방법
• 발신자의 ID를 확인하고 메시지가 전송 중에 변경되지 않았는지 확인하는 HMAC(Hashed Message Authentication Codes: 해시된 메시지 인증 코드) 방식
• encryption-key-determination 알고리즘의 수준을 결정하는 Diffie-Hellman 그룹. 보안 어플라이언스는 이 알고리즘을 사용하여 암호화 및 해시 키를 파생합니다.
• 보안 어플라이언스가 교체 전 암호화 키를 사용하는 시간에 대한 제한입니다.

첫 번째 패킷은 이미지에 표시된 대로 IKE 협상의 이니시에이터에 의해 전송됩니다:

 

참고: Main Mode 1은 IKE 협상의 첫 번째 패킷입니다. 따라서 이니시에이터 SPI는 임의의 값으로 설정되는 반면 응답자 SPI는 0으로 설정됩니다.  두 번째 패킷(MM2)에서 Responder SPI에 새 값으로 응답해야 하며 전체 협상이 동일한 SPI 값을 유지합니다.

MM1을 캡처하고 Wireshark 네트워크 프로토콜 분석기를 사용하는 경우 SPI 값은 다음 그림과 같이 Internet Security Association 및 Key Management Protocol 내용 내에 있습니다.

참고: MM1 패킷이 경로에서 손실되거나 MM2 응답이 없는 경우 IKE 협상은 최대 재전송 수에 도달할 때까지 MM1 재전송 상태를 유지합니다. 이 시점에서 이니시에이터는 다음 협상이 다시 트리거될 때까지 동일한 SPI를 유지합니다.

팁: Initiator 및 Responder SPI 식별은 동일한 VPN에 대한 여러 협상을 식별하고 일부 협상 문제를 좁히는 데 매우 유용합니다.

2개의 동시 협상 식별

Cisco IOS® XE 플랫폼에서는 구성된 원격 IP 주소에 대해 조건부 조건으로 터널별로 디버그를 필터링할 수 있습니다. 그러나 동시 협상이 로그에 표시되며, 이를 필터링할 방법이 없습니다. 수동으로 수행해야 합니다. 앞에서 언급한 것처럼 전체 협상은 이니시에이터 및 응답자에 대해 동일한 SPI 값을 유지합니다. 패킷이 동일한 피어 IP 주소에서 수신되었지만 협상이 최대 재전송 수에 도달하기 전에 추적된 이전 값과 SPI가 일치하지 않는 경우, 이미지에 표시된 것과 같은 동일한 피어에 대한 또 다른 협상입니다.

주: 이 예에서는 협상(MM1)의 첫 번째 패킷에 대한 동시 협상을 보여 줍니다. 그러나 이는 어느 협상 지점에서 발생할 수 있다. 모든 후속 패킷은 응답자 SPI에서 0과 다른 값을 포함해야 합니다.

기본 모드 2(MM2)

기본 모드 2 패킷에서 응답자는 일치하는 제안에 대해 선택한 정책을 전송하고 응답자 SPI는 임의의 값으로 설정됩니다. 전체 협상은 동일한 SPI 값을 유지합니다. MM2는 MM1에 응답하고 SPI 응답자는 그림과 같이 0과 다른 값으로 설정됩니다.

MM2를 캡처하고 Wireshark 네트워크 프로토콜 분석기를 사용하는 경우 이미지에 표시된 대로 Initiator SPI 및 Responder SPI 값이 Internet Security Association 및 Key Management Protocol 내용 내에 있습니다.

기본 모드 3 및 4(MM3-MM4)

MM3 및 MM4 패킷은 여전히 암호화되지 않고 인증되지 않으며 비밀 키 교환이 발생합니다. 다음 이미지에 MM3 및 MM4가 표시됩니다.

기본 모드 5 및 6(MM5-MM6)

MM5 및 MM6 패킷은 이미 암호화되어 있지만 여전히 인증되지 않은 상태입니다. 이러한 패킷에서는 이미지에 표시된 대로 인증이 수행됩니다:

빠른 모드(QM1, QM2 및 QM3)

Quick(빠른) 모드는 Main(기본) 모드와 IKE가 1단계에서 보안 터널을 설정한 후에 발생합니다. 빠른 모드는 IPSec 보안 알고리즘에 대해 공유 IPSec 정책을 협상하고 IPSec SA 설정에 대한 키 교환을 관리합니다. 임시 번호는 새로운 공유 암호 키 자료를 생성하고 생성된 가짜 SA의 재생 공격을 방지하는 데 사용됩니다.

이 단계에서는 그림과 같이 세 개의 패킷이 교환됩니다.

적극적인 모드 패킷 교환

 적극적인 모드에서는 IKE SA 협상을 3개의 패킷으로 압축하며, SA에 필요한 모든 데이터는 이니시에이터에 의해 전달됩니다.

• 응답자는 제안서, 키 자료, ID를 전송하고 다음 패킷에서 세션을 인증합니다.
• 이니시에이터가 세션에 응답하고 인증합니다.
• 협상이 더 빠르며, 이니시에이터 및 응답자 ID는 일반 상태로 전달됩니다.

이 그림에서는 Aggressive 모드에서 교환된 세 패킷에 대한 페이로드 내용을 보여 줍니다.

기본 모드와 적극적인 모드

Aggressive Mode(어그레시브 모드)는 Main Mode(기본 모드)와 비교하여 세 가지 패키지로 제공됩니다.

• AM 1은 MM1과 MM3를 흡수합니다.
• AM 2는 MM2, MM4 및 MM6의 일부를 흡수합니다. 이것이 Aggressive Mode의 취약성이 발생하는 부분입니다. AM 2는 IDr 및 암호화되지 않은 인증을 구성합니다. 기본 모드와 달리 이 정보는 암호화됩니다.
• AM 3는 IDi 및 인증을 제공합니다. 이러한 값은 암호화됩니다.

IKEv2 대 IKEv1 패킷 교환

IKEv2 협상에서는 터널을 설정하기 위해 교환되는 메시지가 더 적습니다. IKEv2는 4개의 메시지를 사용하며, IKEv1은 6개의 메시지(기본 모드) 또는 3개의 메시지(적극적인 모드)를 사용합니다.

IKEv2 메시지 유형은 요청 및 응답 쌍으로 정의됩니다. 이 그림에서는 IKEv2와 IKEv1의 패킷 비교 및 페이로드 내용을 보여 줍니다.

참고: 이 문서에서는 IKEv2 패킷 교환에 대해 자세히 다루지 않습니다. 자세한 내용은 IKEv2 패킷 교환 및 프로토콜 레벨 디버깅을 참조하십시오.

정책 기반 및 경로 기반

정책 기반 VPN

이름에서 알 수 있듯이 정책 기반 VPN은 정책의 일치 기준을 충족하는 전송 트래픽에 대한 정책 작업이 포함된 IPsec VPN 터널입니다. Cisco 디바이스의 경우, VPN으로 리디렉션되고 암호화될 트래픽을 지정하기 위해 ACL(Access List)이 설정되고 암호화 맵에 연결됩니다.

트래픽 선택기는 이미지에 표시된 대로 정책에 지정된 서브넷 또는 호스트입니다:

경로 기반 VPN

정책은 필요하지 않습니다. 트래픽은 경로가 있는 터널로 리디렉션되며, 터널 인터페이스를 통한 동적 라우팅을 지원합니다. 트래픽 선택기(VPN을 통해 암호화된 트래픽)는 기본적으로 0.0.0.0~0.0.0.0입니다(그림 참조).

참고: Traffic(트래픽) 선택기가 0.0.0.0이므로 모든 호스트 또는 서브넷이 여기에 포함됩니다. 따라서 하나의 SA만 생성됩니다. 동적 터널에 대한 예외가 있습니다. 이 문서에서는 동적 터널에 대해 설명하지 않습니다.

정책 및 경로 기반 VPN은 이미지에 표시된 대로 구체화할 수 있습니다:

참고: 하나의 SA만 생성된 경로 기반 VPN과 달리 정책 기반 VPN은 여러 SA를 생성할 수 있습니다. ACL을 설정하면 ACL의 각 명령문이 서로 다른 경우 하위 터널을 생성합니다.

VPN을 통해 수신되지 않는 트래픽의 일반적인 문제

ISP 차단 UDP 500/4500

ISP(Internet Services Provider)가 UDP 500/4500 포트를 차단하는 것은 매우 일반적인 문제입니다. IPsec 터널 설정의 경우 서로 다른 두 ISP를 연결할 수 있습니다. 그중 하나는 포트를 차단할 수 있고 다른 하나는 포트를 허용합니다.

이 이미지는 ISP가 UDP 500/4500 포트를 한 방향으로만 차단할 수 있는 두 가지 시나리오를 보여줍니다:

참고: 포트 UDP 500은 IKE(Internet Key Exchange)에서 보안 VPN 터널을 설정하는 데 사용됩니다. UDP 4500은 NAT가 하나의 VPN 엔드포인트에 있을 때 사용됩니다.

참고: ISP가 UDP 500/4500을 차단하면 IPsec 터널 설정에 영향을 미쳐 작동되지 않습니다.

ISP 차단 ESP

IPsec 터널에서 자주 발생하는 또 다른 문제는 ISP가 ESP 트래픽을 차단하지만 UDP 500/4500 포트는 허용합니다. 예를 들어, UDP 500/4500 포트는 양방향 방식으로 허용됩니다. 따라서 터널이 성공적으로 설정되지만 ISP 또는 ISP에서 양방향으로 ESP 패킷을 차단합니다. 이렇게 하면 VPN을 통과하는 암호화된 트래픽이 이미지에 표시된 대로 실패합니다.

참고: ISP가 ESP 패킷을 차단하면 IPsec 터널 설정이 성공하지만 암호화된 트래픽은 영향을 받습니다. VPN up에 반영될 수 있지만 트래픽이 이를 통해 작동하지 않습니다. 

팁: ESP 트래픽이 한 방향으로만 차단된 시나리오도 존재할 수 있습니다. 증상은 동일하지만 터널 통계 정보, 캡슐화, 역캡슐화 카운터 또는 RX 및 TX 카운터를 사용하여 쉽게 찾을 수 있습니다.

관련 정보

• KEv2 패킷 교환 및 프로토콜 레벨 디버깅
• IKE(Internet Key Exchange) - RFC 2409
• IKEv2(Internet Key Exchange) 프로토콜
• 기술 지원 및 문서 − Cisco Systems