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은 보안 연결(SAS) 및 키 배포의 수동 및 자동 협상을 위한 메소드를 제공합니다. 이 속성은 해석 도메인(DOI)에 수집됩니다. IPsec DOI는 VPN 터널의 성공적인 협상에 필요한 모든 보안 매개 변수에 대한 정의가 들어 있는 문서입니다. 본질적으로 SA 및 보안 협상에 필요한 IKE(Internet Key Exchange) 문서입니다. 자세한 내용은 RFC 2407 및 RFC 2408을 참조하십시오.

IPsec 보안 서비스를 사용하기 위해 호스트 간에 SAS를 생성합니다. SA는 IPsec을 통해 두 호스트가 안전하게 통신할 수 있도록 하는 단순한 연결입니다. SAS에는 두 가지 유형이 있습니다. 수동 및 동적.

IPsec은 두 가지 보안 모드(전송 모드 및 터널 모드)를 지원하며,

보안 협회

SA(Security Association)는 통신 채널을 보호하는 데 사용하는 방법 및 매개 변수에 관한 VPN 참가자들 간의 일방향 계약입니다. 완전한 양방향 통신에는 각 방향에 대해 최소 2개의 SAS가 필요합니다. IPsec 터널은 SA를 통해 다음과 같은 보안 기능을 제공할 수 있습니다.

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

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

  • 발신자 인증 및 인증서를 사용하는 경우—부인(데이터 원본 인증을 통해)

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

IPsec 터널은 한 쌍의 단방향 SA(터널 방향에 하나의 SA로 구성됩니다. 이 터널 방향에는 보안 매개 변수 인덱스), 대상 IP 주소 및 보안 프로토콜(인증 헤더 [AH] 또는 채용된 보안 페이로드 캡슐화 [ESP]를 지정합니다. SA 그룹은 통신을 보안하기 위한 다음과 같은 구성 요소를 함께 구성합니다.

  • 보안 알고리즘 및 키.

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

  • 키 관리 방법, 수동 키 또는 AutoKey IKE(Internet Key Exchange).

  • SA 수명.

인바운드 트래픽의 경우 Junos OS 트리플릿을 사용하여 SA를 룩업합니다.

  • 대상 IP 주소.

  • AH 또는 ESP의 보안 프로토콜을 제공합니다.

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

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

IPsec 키 관리

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

  • 수동 키

  • AutoKey IKE(Internet Key Exchange) 키 또는 인증서가 있는 경우

1단계 및 2단계 제안 구성 중에 인증 방법이라고도 하는 주요 생성 메커니즘을 선택할 수 있습니다. 를 Internet Key Exchange.

이 주제에는 다음 섹션이 포함되어 있습니다.

수동 키

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

AutoKey IKE(Internet Key Exchange)

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

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

    사전 공유 키는 두 참가자 모두 통신을 시작하기 전에 있어야 하는 암호화 및 복호화의 핵심입니다.

  • AutoKey IKE(Internet Key Exchange) 사용—AutoKey IKE(Internet Key Exchange) 협상 중에 인증서를 사용하여 참가자를 인증할 때 각측은 공용 전용 키 쌍을 생성하고 인증서를 획득합니다. 발행 인증서 기관(CA(certificate authority)) 양측이 신뢰할 수 있는 한, 참가자는 피어의 공용 키를 검색하고 피어의 서명을 검증할 수 있습니다. 키와 SAS를 계속 추적할 필요가 없습니다. IKE(Internet Key Exchange) 자동으로 실행됩니다.

Diffie-Hellman Exchange

Diffie-Hellman (DH) 거래소를 통해 참가자들은 공유된 비밀 가치를 생성하게 됩니다. 기술의 강점은 참가자들이 유선으로 보안 값을 전달하지 않고도 보안되지 않는 매체에서 비밀 가치를 생성할 수 있는 기술입니다. 각 그룹의 계산에 사용된 주형의 크기는 아래 표와 같이 차이가 있습니다. Diffie Hellman(DH) 거래소 작업은 소프트웨어나 하드웨어에서 수행할 수 있습니다. 이러한 거래소 작업이 하드웨어에서 수행될 때 주니어는 QuickAssist Technology(QAT) 암호화를 활용합니다. 다음 표 1 목록은 서로 다른 DH(Diffie Hellman) 그룹을 나열하고 해당 그룹에 대해 수행한 작업이 하드웨어에 있는지 또는 소프트웨어인지를 지정합니다.

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

Diffie-Hellman(DH) 그룹

프라임 모듈 크기

DH 그룹 1

768-bit

DH 그룹 2

102-bit

DH 그룹 5

1536-bit

DH 그룹 14

2048-bit

DH 그룹 15

3072-bit

DH 그룹 16

4096-bit

DH 그룹 19

256비트 타원형 곡선

DH Group 20

384비트 타원형 곡선

DH 그룹 21

521비트 타원형 곡선

DH 그룹 24

2048-bit(256비트 프라임 주문 하위 하위단)

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

Junos-ike 패키지가 Junos OS 릴리스 20.3R1 있는 vSRX DH 그룹 15, 16 및 21을 지원하는 인스턴스입니다.

DH 그룹 1, 2 및 5를 사용하지 않는 것이 좋습니다.

각 DH 그룹의 모계는 서로 다른 크기이기 때문에 참가자들은 동일한 그룹을 사용하는 데 동의해야 합니다.

IPsec 보안 프로토콜

IPsec은 IP 계층에서 통신을 보호하는 두 가지 프로토콜을 사용합니다.

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

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

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

각 VPN 터널에 대해 AH 및 ESP 터널 세션이 SPUS(Services Processing Units) 및 컨트롤 플레인에 모두 설치됩니다. 터널 세션은 협상이 완료되면 협상 프로토콜로 업데이트됩니다. 앵커 SRX5400, SRX5600 및 SRX5800 디바이스의 터널 세션은 협상된 프로토콜로 업데이트되고 비 앵커 SPUS는 ESP 및 AH 터널 세션을 보존합니다. ESP 및 AH 터널 세션은 운영 모드 명령의 출력에 show security flow sessionshow security flow cp-session 표시됩니다.

이 주제에는 다음 섹션이 포함되어 있습니다.

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

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

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

  • 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(Internet Key Exchange) 피어 또는 디지털 인증서를 인증하고 IKE(Internet Key Exchange) 인증합니다. 이는 개별 프라이빗 네트워크 내의 호스트가 공용 네트워크를 통해 통신을 원할 때 가장 일반적으로 사용됩니다. 이 모드는 VPN 클라이언트와 VPN 게이트웨이에서 모두 사용할 수 있으며 비 IPsec 시스템으로 오거나 이동하는 통신을 보호합니다.

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

지원되는 IPsec 및 IKE(Internet Key Exchange) 표준

1개 이상의 MS-MC, MS- MIC 또는 DC를 갖춘 라우터에서 캐나다 및 미국 Junos OS 버전은 IPsec(IP Security) 및 Internet Key Exchange(IKE(Internet Key Exchange))에 대한 표준을 정의하는 다음과 같은 RFC를 크게 지원합니다.

  • RFC 2085, HMAC-MD5 IP Authentication with Replay Prevention

  • 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, Explicit IV를 갖는 ESP DES-CBC 암호 알고리즘

  • RFC 2406, IP 캡슐화 보안 페이로드(ESP)(RFC 4303 및 RFC 4305에 의해 사용 후 사용)

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

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

  • RFC 2409, Internet Key Exchange(IKE(Internet Key Exchange))(RFC 4306에 의해 구형)

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

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

  • RFC 2460, 인터넷 프로토콜, 버전 6(IPv6)

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

  • RFC 3193 IPsec을 사용한 L2TP 보안

  • RFC 3280, Internet X.509 CRL(Public Key Infrastructure Certificate and Certificate Revocation List) 프로파일

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

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

  • RFC 4106, IPsec 캡슐화 보안 페이로드(ESP)에서 Galois/Counter 모드(GCM) 사용

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

  • RFC 4211, 인터넷 X.509 공용 핵심 인프라 인증서 요청 메시지 형식(CRMF)

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

  • RFC 4302, IP 인증 헤더

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

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

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

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

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

    Suite VPN-A만 네트워크에서 Junos OS.

  • RFC 4754, IKE(Internet Key Exchange) 및 IKEv2 인증 ECDSA(Elliptic Curve 디지털 서명 알고리즘)을 사용하여

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

  • RFC 5996, Internet Key Exchange 프로토콜 버전 2(IKEv2)

Junos OS IPsec 및 애플리케이션을 위한 다음과 같은 RFC를 부분적으로 IKE(Internet Key Exchange):

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

  • RFC 5114, 추가 Diffie-Hellman 그룹 사용 표준 IETF(Internet Engineering Task Force) 그룹

  • RFC 5903, Elliptic Curve Groups modulo a Prime (ECP Groups) for IKE(Internet Key Exchange) 및 IKEv2

다음 RFC 및 인터넷 초안은 표준을 정의하지 않지만 IPsec, IKE(Internet Key Exchange) 관련 기술에 대한 정보를 제공합니다. 이 IETF(Internet Engineering Task Force) 정보로 분류합니다.

  • RFC 2104, HMAC: 메시지 인증을 위한 키로 해시(keyed-hashing)

  • RFC 2412, OAKLEY 키 결정 프로토콜

  • RFC 3706 : 피어(dead Internet Key Exchange)IKE(Internet Key Exchange) 트래픽 기반 방법

  • 인터넷 draft-eastlake-sha2-02.txt, US Secure Hash 알고리즘(SHA 및 HMAC-SHA) (2006년 7월 만료)

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