Help us improve your experience.

Let us know what you think.

Do you have time for a two-minute survey?

 
 

IPsec 기본

IPsec 개요

IPsec은 IP 패킷 레이어에서 통신을 암호화하여 보호하기 위한 관련 프로토콜 제품군입니다. 또한 IPsec은 보안 연결(SA)과 키 배포의 수동 및 자동 협상 방법( 모든 속성이 해석 도메인(DOI)에 수집되는 방법을 제공합니다. IPsec DOI는 VPN 터널의 성공적인 협상에 필요한 모든 보안 매개 변수에 대한 정의가 포함된 문서입니다. 기본적으로 SA 및 IKE 협상에 필요한 모든 속성입니다. 자세한 내용은 RFC 2407 및 RFC 2408을 참조하십시오.

IPsec 보안 서비스를 사용하려면 호스트 간에 SA를 생성합니다. SA는 2개의 호스트가 IPsec을 통해 안전하게 상호 통신할 수 있도록 해주는 Simplex 연결입니다. 다음과 같은 2가지 유형의 SA가 있습니다. 수동 및 동적입니다.

IPsec은 2가지 보안 모드(전송 모드 및 터널 모드)를 지원합니다.

보안 연결

보안 연결(SA)은 통신 채널 보안에 사용할 방법과 매개 변수와 관련하여 VPN 참여자 간의 단방향 계약입니다. 완전한 양방향 통신을 위해서는 각 방향에 대해 최소 2개의 SA가 필요합니다. SA를 통해 IPsec 터널은 다음과 같은 보안 기능을 제공할 수 있습니다.

  • 개인 정보 보호(암호화를 통해)

  • 컨텐트 무결성(데이터 인증을 통해)

  • 보낸 사람 인증 및 인증서를 사용하는 경우 비공급(데이터 발신 인증을 통해)

사용하는 보안 기능은 필요에 따라 달라집니다. IP 패킷 소스 및 컨텐트 무결성을 인증하기만 하면 암호화를 적용하지 않고 패킷을 인증할 수 있습니다. 반면 개인정보 보호에만 관심이 있는 경우 인증 메커니즘을 적용하지 않고 패킷을 암호화할 수 있습니다. 선택적으로 패킷을 암호화하고 인증할 수 있습니다. 대부분의 네트워크 보안 설계자는 VPN 트래픽을 암호화, 인증 및 재생 보호하도록 선택합니다.

IPsec 터널은 한 쌍의 단방향 SA(터널의 각 방향을 위한 하나의 SA)로 구성되어 있으며, 이 SLA는 SPI(Security Parameter Index), 대상 IP 주소 및 보안 프로토콜(인증 헤더[AH] 또는 고용된 Encapsulating Security Payload[ESP])을 지정합니다. SA는 통신을 보호하기 위해 다음과 같은 구성 요소를 함께 그룹화합니다.

  • 보안 알고리즘 및 키.

  • 프로토콜 모드, 전송 또는 터널 중 하나. Junos OS 디바이스는 항상 터널 모드를 사용합니다. ( 터널 모드의 패킷 처리 참조)

  • 키 관리 방식(수동 키 또는 AutoKey IKE) 중 하나.

  • SA 수명.

인바운드 트래픽의 경우 Junos OS는 다음과 같은 트리플렛을 사용하여 SA를 조회합니다.

  • 대상 IP 주소.

  • 보안 프로토콜( AH 또는 ESP)

  • SPI(Security 매개 변수 인덱스) 값.

아웃바운드 VPN 트래픽의 경우 이 정책은 VPN 터널과 연관된 SA를 호출합니다.

IPsec 키 관리

키의 배포 및 관리는 VPN을 성공적으로 사용하는 데 매우 중요합니다. Junos OS는 다음과 같은 3가지 핵심 생성 메커니즘을 통해 VPN 터널을 생성하기 위한 IPsec 기술을 지원합니다.

  • 수동 키

  • 사전 공유 키 또는 인증서를 갖춘 AutoKey IKE

1단계 및 2단계 제안 구성 중에 인증 메소드라고도 하는 키 생성 메커니즘을 선택할 수 있습니다. Internet Key Exchange를 참조하십시오.

이 항목에는 다음 섹션이 포함됩니다.

수동 키

터널의 양 끝에 있는 관리자는 수동 키를 통해 모든 보안 매개변수를 구성합니다. 이는 키의 배포, 유지 관리 및 추적이 어렵지 않은 소규모의 정적 네트워크에서 유용한 기법입니다. 하지만 멀리 떨어진 곳에 수동 키 구성을 안전하게 배포하는 것은 보안 문제를 야기합니다. 키를 직접 전달하는 것을 제외하고, 전송 중 키가 손상되지 않는다는 보장이 없기 때문입니다. 또한, 키를 변경하려 할 때마다 처음에 키를 배포할 때와 같은 보안 문제에 직면하게 됩니다.

AutoKey IKE

많은 터널을 생성하고 관리해야 하는 경우 모든 요소를 수동으로 구성할 필요가 없는 방법이 필요합니다. IPsec은 IKE(Internet Key Exchange) 프로토콜을 사용하여 키 및 보안 연결의 자동화된 생성 및 협상을 지원합니다. Junos OS는 AutoKey IKE와 같은 자동화된 터널 협상을 의미하며 사전 공유된 키가 있는 AutoKey IKE와 인증서가 있는 AutoKey IKE를 지원합니다.

  • 사전 공유 키가 있는 AutoKey IKE—사전 공유된 키가 있는 AutoKey IKE를 사용하여 IKE 세션 참가자를 인증하려면 양측이 사전에 사전 공유 키를 구성하고 안전하게 교환해야 합니다. 이와 관련하여, 보안 키 배포 문제는 수동 키와 동일합니다. 그러나 일단 분산되면 수동 키와 달리 자동 키는 IKE 프로토콜을 사용하여 정해진 간격으로 키를 자동으로 변경할 수 있습니다. 키를 자주 변경하면 보안이 크게 향상되고 자동으로 키를 관리해야 하는 책임이 크게 줄어듭니다. 그러나 키를 변경하면 트래픽 오버헤드가 증가합니다. 따라서 키를 너무 자주 변경하면 데이터 전송 효율성을 줄일 수 있습니다.

    사전 공유 키는 암호화 및 암호 해독을 위한 키로, 두 참가자 모두 통신을 시작하기 전에 반드시 가져야 합니다.

  • AutoKey IKE(AutoKey IKE) 인증서—AutoKey IKE 협상 중 참가자를 인증하기 위해 인증서를 사용할 때 각 팀은 공용-전용 키 쌍을 생성하고 인증서를 획득합니다. 발행 CA(Certificate Authority)를 양쪽에서 신뢰하는 한 참가자는 피어의 공개 키를 검색하고 피어의 서명을 검증할 수 있습니다. 키와 SA를 계속 추적할 필요가 없습니다. IKE는 자동으로 수행합니다.

디피 헬만 익스체인지

DH(Diffie-Hellman) 교환을 통해 참가자들은 공유된 비밀 가치를 창출할 수 있습니다. 기술의 강점은 참가자들이 유선을 통해 암호 값을 전달하지 않고도 보안되지 않은 매체상에서 암호 값을 생성할 수 있다는 것입니다. 각 그룹의 계산에 사용되는 주요 모듈의 크기는 아래 표와 같이 다릅니다. DH(Diffie Hellman) 거래소 운영은 소프트웨어 또는 하드웨어에서 수행할 수 있습니다. 이러한 교환 작업이 하드웨어에서 수행되면 주니퍼는 QAT(QuickAssist Technology) 암호화를 활용합니다. 다음은 표 1 여러 DH(Diffie Hellman) 그룹을 나열하고 해당 그룹에 대해 수행된 작업이 하드웨어 또는 소프트웨어인지 여부를 지정합니다.

표 1: DH(Diffie Hellman) 그룹과 거래소 운영 수행

디피 헬만(DH) 그룹

프라임 모듈 크기

DH Group 1

768-bit

DH Group 2

102-bit

DH Group 5

1536-bit

DH Group 14

2048-bit

DH Group 15

3072-bit

DH Group 16

4096-bit

DH Group 19

256비트 타원 곡선

DH Group 20

384비트 타원 곡선

DH Group 21

521비트 타원 곡선

DH Group 24

256비트 프라임 오더 서브그룹이 포함된 2048비트

Junos OS 릴리스 19.1R1부터 SRX 시리즈 디바이스는 DH 그룹 15, 16, 21을 지원합니다.

Junos OS 릴리스 20.3R1부터 시작하여 junos-ike 패키지가 설치된 vSRX 인스턴스는 DH 그룹 15, 16, 21을 지원합니다.

DH 그룹 1, 2 및 5의 사용을 권장하지 않습니다.

각 DH 그룹의 모듈러스는 크기가 다르기 때문에 참가자는 동일한 그룹을 사용하는 데 동의해야 합니다.

IPsec 보안 프로토콜

IPsec은 IP 레이어에서 통신을 보호하기 위해 다음과 같은 두 가지 프로토콜을 사용합니다.

  • AH(Authentication Header)—IP 패킷의 소스를 인증하고 컨텐트의 무결성을 검증하기 위한 보안 프로토콜

  • ESP(Encapsulating Security Payload)—전체 IP 패킷을 암호화하고 컨텐트 인증을 위한 보안 프로토콜

2단계 제안 구성 중에 인증 및 암호화 알고리즘이라고도 하는 보안 프로토콜을 선택할 수 있습니다. Internet Key Exchange를 참조하십시오.

각 VPN 터널의 경우, AH 및 ESP 터널 세션은 SPU(Services Processing Unit)와 컨트롤 플레인에 설치됩니다. 터널 세션은 협상 완료 후 협상 프로토콜로 업데이트됩니다. SRX5400, SRX5600 및 SRX5800 디바이스의 경우 앵커 SPU의 터널 세션이 협상된 프로토콜로 업데이트되며, 비 앵커 SPU는 ESP 및 AH 터널 세션을 유지합니다. ESP 및 AH 터널 세션은 및 show security flow cp-session 작동 모드 명령의 출력 show security flow session 에 표시됩니다.

이 항목에는 다음 섹션이 포함됩니다.

IPsec 인증 알고리즘(AH 프로토콜)

AH(Authentication Header) 프로토콜은 패킷의 컨텐트 및 원본의 진위와 무결성을 검증하는 방법을 제공합니다. 암호 키와 MD5 또는 SHA 해시 기능을 사용하여 해시 메시지 인증 코드(HMAC)를 통해 계산된 체크섬으로 패킷을 인증할 수 있습니다.

  • Message Digest 5(MD5)—임의 길이의 메시지와 16바이트 키로부터 128비트 해시( 디지털 서명 또는 메시지 다이제스트라고도 함)를 생성하는 알고리즘. 그 결과 생성된 해시는 입력된 지문과 같이 컨텐트 및 소스의 신뢰성과 무결성을 검증하는데 사용됩니다.

  • SHA(Secure Hash Algorithm)—임의 길이의 메시지와 20바이트 키로부터 160비트 해시를 생성하는 알고리즘. 이 알고리즘의 경우 생성되는 해시 크기가 더 크기 때문에 일반적으로 MD5보다 더욱 안전하다고 알려져 있습니다. 연산 처리는 ASIC에서 수행되므로 성능 비용은 무시할 수 없습니다.

MD5 해시 알고리즘에 대한 자세한 내용은 RFC 1321 및 RFC 2403을 참조하십시오. SHA 해시 알고리즘에 대한 자세한 내용은 RFC 2404를 참조하십시오. HMAC에 대한 자세한 내용은 RFC 2104를 참조하십시오.

IPsec 암호화 알고리즘(ESP 프로토콜)

ESP(Encapsulating Security Payload) 프로토콜은 프라이버시(암호화) 및 소스 인증 및 컨텐트 무결성(인증)을 보장하는 방법을 제공합니다. 터널 모드의 ESP는 전체 IP 패킷(헤더 및 페이로드)을 캡슐화한 다음 현재 암호화된 패킷에 새로운 IP 헤더를 추가합니다. 이러한 새 IP 헤더에는 네트워크를 통해 보호된 데이터를 라우팅하는 데 필요한 대상 주소가 포함되어 있습니다. ( 터널 모드의 패킷 처리 참조)

ESP를 사용하면 암호화 및 인증, 암호화만 또는 인증만 수행할 수 있습니다. 암호화의 경우 다음과 같은 암호화 알고리즘 중 하나를 선택할 수 있습니다.

  • DES(Data Encryption Standard)— 56비트 키를 사용한 암호화 블록 알고리즘.

  • 3DES(Triple DES)— 168비트 키를 사용하여 세 번의 라운드(round)에서 원래의 DES 알고리즘을 적용한 더욱 강력한 버전의 DES. DES는 상당한 성능 절감을 제공하지만 많은 분류 자료 또는 민감한 자료 전송에는 허용되지 않는 것으로 간주됩니다.

  • AES(Advanced Encryption Standard)—다른 장치와의 상호 운용성을 높이는 암호화 표준입니다. Junos OS는 128비트, 192비트, 256비트 키로 AES를 지원합니다.

인증을 위해 MD5 또는 SHA 알고리즘을 사용할 수 있습니다.

암호화를 위해 NULL을 선택할 수 있지만 IPsec이 이러한 상황에서 공격에 취약할 수 있음을 입증했습니다. 따라서 보안을 극대화하기 위해 암호화 알고리즘을 선택할 것을 권장합니다.

IPsec 터널 협상

VPN에서 트래픽 교환 방법을 결정하는 다음과 같은 2가지 모드

  • 터널 모드—VPN 터널의 다른 패킷 내에 원래 IP 패킷을 캡슐화하여 트래픽을 보호합니다. 이 모드는 IKE와 사전 공유된 키를 사용하여 피어 또는 IKE를 통한 디지털 인증서를 인증하여 피어를 인증합니다. 이는 개별 프라이빗 네트워크 내의 호스트가 공용 네트워크를 통해 통신을 원할 때 가장 일반적으로 사용됩니다. 이 모드는 VPN 클라이언트 및 VPN 게이트웨이에서 모두 사용할 수 있으며 비 IPsec 시스템에서 발생하거나 이동되는 통신을 보호합니다.

  • 전송 모드—IPsec 터널을 구축한 두 호스트 간에 패킷을 직접 전송하여 트래픽을 보호합니다. 통신 단말 장치와 암호화 단말 장치도 동일한 경우입니다. IP 패킷의 데이터 부분은 암호화되지만 IP 헤더는 암호화되지 않습니다. 보호된 호스트를 위한 암호화 및 복호화 서비스를 제공하는 VPN 게이트웨이는 보호된 VPN 통신을 위해 전송 모드를 사용할 수 없습니다. 패킷이 가로채면 소스 또는 대상의 IP 주소를 수정할 수 있습니다. 통신 단말 장치 및 암호화 단말 장치와 동일한 경우에만 전송 모드를 사용할 수 있습니다.

지원되는 IPsec 및 IKE 표준

하나 이상의 MS-MPC, MS-MIC 또는 DPC를 갖춘 라우터에서 캐나다와 미국 버전의 Junos OS는 IPsec(IP Security) 및 IKE(Internet Key Exchange)에 대한 표준을 정의하는 다음 RFC를 실질적으로 지원합니다.

  • RFC 2085, HMAC-MD5 재생 방지를 통한 IP 인증

  • RFC 2401, 인터넷 프로토콜을 위한 보안 아키텍처 (RFC 4301에 의해 구식)

  • RFC 2402, IP 인증 헤더 (RFC 4302로 노후화)

  • RFC 2403, ESP 및 AH 내에서 HMAC-MD5-96 사용

  • RFC 2404, ESP 및 AH 내에서 HMAC-SHA-1-96 사용 (RFC 4305에 의해 노후화)

  • RFC 2405, 명시적 IV를 갖춘 ESP DES-CBC 암호문 알고리즘

  • RFC 2406, IP ESP(Encapsulating Security Payload) (RFC 4303 및 RFC 4305로 노후화)

  • RFC 2407, ISAKMP를 위한 인터넷 IP 보안 해석 도메인 (RFC 4306에 의해 노후화)

  • RFC 2408, 인터넷 보안 협회 및 ISAKMP(Key Management Protocol) (RFC 4306에 의해 노후화)

  • RFC 2409, IKE(Internet Key Exchange) (RFC 4306에 의해 노후화)

  • RFC 2410 , NULL 암호화 알고리즘 및 IPsec 사용

  • RFC 2451, ESP CBC-모드 암호문 알고리즘

  • RFC 2560, X.509 인터넷 공용 키 인프라 온라인 인증서 상태 프로토콜 - OCSP

  • RFC 3193, IPsec을 사용한 L2TP 보안

  • RFC 3280, Internet X.509 공용 키 인프라 인증서 및 CRL(Certificate Revocation List) 프로필

  • RFC 3602, AES-CBC 암호문 알고리즘 및 IPsec 사용

  • RFC 3948, IPsec ESP 패킷의 UDP 캡슐화

  • RFC 4106, IPsec ESP(Encapsulating Security Payload)에서 GCM(Galois/Counter Mode)의 사용

  • RFC 4210, Internet X.509 CMP(Public Key Infrastructure Certificate Management Protocol)

  • RFC 4211, Internet X.509 CRMF(Public Key Infrastructure Certificate Request Message Format)

  • RFC 4301, 인터넷 프로토콜을 위한 보안 아키텍처

  • RFC 4302, IP 인증 헤더

  • RFC 4303, ESP(IP 캡슐화 보안 페이로드)

  • RFC 4305, ESP(Encapsulating Security Payload) 및 AH(Authentication Header)를 위한 암호화 알고리즘 구현 요구 사항

  • RFC 4306, IKEv2(Internet Key Exchange) 프로토콜

  • RFC 4307, IKEv2(Internet Key Exchange Version 2)에서 사용하기 위한 암호화 알고리즘

  • RFC 4308, IPsec용 암호화 제품군

    오직 Suite VPN-A만이 Junos OS에서 지원됩니다.

  • RFC 4754, IKE 및 IKEv2 ECDSA(Elliptic Curve Digital Signature Algorithm)를 사용한 인증

  • RFC 4835, ESP(Encapsulating Security Payload) 및 AH(Authentication Header)를 위한 암호화 알고리즘 구현 요구 사항

  • RFC 5996, IKEv2(Internet Key Exchange Protocol Version 2) (RFC 7296에 의해 노후화)

  • RFC 7296, IKEv2(Internet Key Exchange Protocol Version 2)

  • RFC 8200, IPv6(Internet Protocol, Version 6) 사양

Junos OS는 IPsec 및 IKE에 대해 다음 RFC를 부분적으로 지원합니다.

  • RFC 3526, IKE(Internet Key Exchange)를 위한 MODP(Modular Exponential) Diffie-Hellman 그룹

  • RFC 5114, IETF 표준과 함께 사용할 수 있는 추가 Diffie-Hellman 그룹

  • RFC 5903, Elliptic Curve Group IKE 및 IKEv2를 위한 ECP 그룹(ECP Group) modulo a Prime

다음 RFC 및 인터넷 초안은 표준을 정의하지 않고 IPsec, IKE 및 관련 기술에 대한 정보를 제공합니다. IETF는 이를 "정보"로 분류합니다.

  • RFC 2104, HMAC: 메시지 인증을 위한 키드 해시

  • RFC 2412, 오클리 키 결정 프로토콜

  • RFC 3706 - IKE(Dead Internet Key Exchange) 피어 탐지를 위한 트래픽 기반 방법

  • 인터넷 초안 draft-eastlake-sha2-02.txt, US Secure Hash Algorithms(SHA 및 HMAC-SHA) (2006년 7월 만료)

출시 내역 표
릴리스
설명
19.1R1
Junos OS 릴리스 19.1R1부터 SRX 시리즈 디바이스는 DH 그룹 15, 16, 21을 지원합니다.