동적 보안 연결

IKE(Internet Key Exchange) 제안에 대한 인증 알고리즘을 구성하려면 계층 수준에서 [edit services ipsec-vpn ike proposal proposal-name] 문을 포함 authentication-algorithm 합니다.

인증 알고리즘은 다음 중 하나가 될 수 있습니다.

• md5—128비트 다이제스트를 생성합니다.

• sha1—160비트 다이제스트를 생성합니다.

• sha-256- 256비트 다이제스트를 생성합니다.

  참고:

  보안 해시 알고리즘(SHA)에 대한 참조 정보는 인터넷 초안 draft-eastlake-sha2-02.txt, 보안 해시 알고리즘(SHA 및 HMAC-SHA)( 2006년 7월 만료)을 참조하십시오.

IKE(Internet Key Exchange) 제안에 대한 인증 방법을 구성하려면 계층 수준에서 [edit services ipsec-vpn ike proposal proposal-name] 문을 포함 authentication-method 합니다.

참고:

IKEv1에서 SA에 대한 인증 방법은 IKE 제안에 구성된 인증 방법의 유형을 기반으로 원격 피어와 인증됩니다. IKEv2에서는 이러한 협상이 원격 피어와 수행되지 않습니다. 대신 각 IKE(Internet Key Exchange) 피어는 로컬로 구성된 인증 방법을 사용합니다.

IKEv2의 SA에 대해 IKE(Internet Key Exchange) 제안에 인증 방법이 구성되지 않은 경우 인증 방법은 IKEv1의 기본값입니다. IKEv2에 대한 인증 방법을 구성하는 경우, 정책에서 참조되는 모든 제안에 대해 동일한 인증 방법을 구성해야 합니다.

인증 방법은 다음 중 하나입니다.

참고:

Junos FIPS 모드에서 ECDSA는 Junos OS 릴리스 17.3R1의 인증 방법에 지원되지 않습니다. Junos OS 릴리스 17.4R1부터 ECDSA는 Junos FIPS 모드에서 지원됩니다.

• ecdsa-signatures-256—MS-MPC 및 MS-MIC용 Junos OS 릴리스 17.3R1부터 256비트 모듈리용 ECDSA(Elliptic Curve Digital Signature Algorithm)가 적용됩니다.

• ecdsa-signatures-384—MS-MPC 및 MS-MIC용 Junos OS 릴리스 17.3R1부터 384비트 모듈리용 ECDSA(Elliptic Curve Digital Signature Algorithm)가 적용됩니다.

• pre-shared-keys—대역 외 메커니즘에서 파생된 키; 키는 교환을 인증합니다.

• rsa-signatures—공개 키 알고리즘(암호화 및 디지털 서명 지원).

Diffie-Hellman은 두 당사자가 안전하지 않은 통신 채널을 통해 공유 암호를 설정할 수 있도록 하는 공개 키 암호화 체계입니다. 또한 IKE(Internet Key Exchange) 내에서 세션 키를 설정하는 데 사용됩니다.

IKE(Internet Key Exchange) 제안에 대해 Diffie-Hellman 그룹을 구성하려면 계층 수준에서 문을 포함 dh-group 합니다.[edit services ipsec-vpn ike proposal proposal-name]

그룹은 다음 중 하나일 수 있습니다.

• group1- 새로운 Diffie-Hellman 교환을 수행할 때 IKE가 768비트 Diffie-Hellman 프라임 모듈러스 그룹을 사용하도록 지정합니다.

• group2- IKE(Internet Key Exchange)가 새로운 Diffie-Hellman 교환을 수행할 때 1024비트 Diffie-Hellman 프라임 모듈러스 그룹을 사용하도록 지정합니다.

• group5- 새로운 Diffie-Hellman 교환을 수행할 때 IKE가 1536비트 Diffie-Hellman 프라임 모듈러스 그룹을 사용하도록 지정합니다.

• group14- 새로운 Diffie-Hellman 교환을 수행할 때 IKE가 2048비트 Diffie-Hellman 프라임 모듈러스 그룹을 사용하도록 지정합니다.

• group19- IKE가 새로운 Diffie-Hellman 교환을 수행할 때 256비트 임의 Elliptic Curve Diffie-Hellman 그룹을 사용하도록 지정합니다.

• group20—-IKE가 새로운 Diffie-Hellman 교환을 수행할 때 384비트 임의 Elliptic Curve Diffie-Hellman Group을 사용하도록 지정합니다.

Junos OS 릴리스 17.4R1부터는 group15, group16 및 group 24도 사용할 수 있습니다.

• group15- 새로운 Diffie-Hellman 교환을 수행할 때 IKE가 3072비트 Diffie-Hellman 기본 모듈러스 그룹을 사용하도록 지정합니다.

• group16- 새로운 Diffie-Hellman 교환을 수행할 때 IKE가 4096비트 Diffie-Hellman 소수 모듈러스 그룹을 사용하도록 지정합니다.

• group24- IKE가 새로운 Diffie-Hellman 교환을 수행할 때 256비트 프라임 오더 하위 그룹과 함께 2048비트 Diffie-Hellman 프라임 모듈러스 그룹을 사용하도록 지정합니다.

더 많은 비트 수를 기반으로 하는 Diffie-Hellman 그룹을 사용하면 더 적은 수의 비트를 기반으로 하는 그룹을 사용하는 것보다 더 안전한 IKE 터널을 만들 수 있습니다. 그러나 이러한 추가 보안을 위해서는 추가 처리 시간이 필요할 수 있습니다.

IKE(Internet Key Exchange) 제안에 대한 암호화 알고리즘을 구성하려면 계층 수준에서 [edit services ipsec-vpn ike proposal proposal-name] 문을 포함 encryption-algorithm 합니다.

암호화 알고리즘은 다음 중 하나가 될 수 있습니다.

• 3des-cbc—키 크기가 24바이트인 암호 블록 체인 암호화 알고리즘; 키 크기는 192비트입니다.

• des-cbc—키 크기가 8바이트인 암호 블록 체인 암호화 알고리즘; 키 크기는 56비트입니다.

• aes-128-cbc- 고급 암호화 표준(AES) 128비트 암호화 알고리즘.

• aes-192-cbc—고급 암호화 표준(AES) 192비트 암호화 알고리즘.

• aes-256-cbc- 고급 암호화 표준(AES) 256비트 암호화 알고리즘.

참고:

DES(Data Encryption Standard) 암호화 알고리즘의 약한 키와 반약한 키의 목록은 RFC 2409, The Internet Key Exchange(IKE)를 참조하십시오. AES 암호화 알고리즘은 처리량이 훨씬 낮은 소프트웨어 구현을 사용하므로 DES가 여전히 권장되는 옵션입니다.

의 경우 3des-cbc처음 8바이트는 두 번째 8바이트와 달라야 하며 두 번째 8바이트는 세 번째 8바이트와 동일해야 합니다.

인증 제안을 구성하지만 문을 포함 encryption 하지 않으면 결과는 NULL 암호화입니다. 특정 애플리케이션에서는 이러한 결과를 예상합니다. 특정 인증 또는 암호화 값을 구성하지 않으면, Junos OS는 인증 및 3des-cbc 암호화에 대한 기본값을 사용합니다sha1.

명령문은 lifetime-seconds IKE(Internet Key Exchange) SA의 수명을 설정합니다. IKE(Internet Key Exchange) SA가 만료되면 새로운 SA(및 SPI)로 대체되거나 IPsec 연결이 종료됩니다.

IKE(Internet Key Exchange) SA의 수명을 구성하려면 계층 수준에서 문을 포함 lifetime-seconds 합니다.[edit services ipsec-vpn ike proposal proposal-name]

기본적으로 IKE(Internet Key Exchange) SA 수명은 3,600초입니다. 범위는 180초에서 86,400초입니다.

참고:

IKEv1에서 SA의 수명은 IKE 제안에 구성된 수명 유형에 따라 원격 피어와 협상됩니다. IKEv2에서는 이러한 협상이 원격 피어와 수행되지 않습니다. 대신 각 IKE(Internet Key Exchange) 피어는 로컬로 구성된 수명을 사용합니다.

IKEv2의 SA의 경우 수명은 IKEv1의 기본값(IKE 제안에 다른 수명이 구성되지 않은 경우)이거나 IKE 정책의 모든 IKEv2 제안이 동일한 수명 값으로 구성되어야 합니다.

참고:

IKE(Internet Key Exchange) 제안의 경우, Junos OS에 의해 지정된 하나의 SA 수명 값은 있습니다. IPsec 제안은 다른 메커니즘을 사용합니다.

IKE(Internet Key Exchange) 제안을 구성합니다.

Junos OS 릴리스 11.4부터 기본적으로 모든 M Series, MX 시리즈 및 T 시리즈 라우터에서 IKEv1과 IKEv2가 모두 지원됩니다. 협상에 지원될 특정 IKE 단계를 구성할 수 있습니다. 그러나 IKEv1만 지원되는 경우, Junos OS는 IKEv2 협상을 거부합니다. 마찬가지로 IKEv2만 지원되는 경우, Junos OS는 모든 IKEv1 협상을 거부합니다.

사용되는 IKE(Internet Key Exchange) 단계를 구성하려면 계층 수준에서 [edit services ipsec-vpn ike policy policy-name] 문을 포함 version 합니다.

IKE(Internet Key Exchange) 정책에는 공격적(aggressive) 및 기본(main)의 두 가지 모드가 있습니다. 기본적으로 기본 모드가 활성화되어 있습니다. 메인 모드는 세 번의 교환에서 6개의 메시지를 사용하여 IKE(Internet Key Exchange) SA를 설정합니다. (이 세 단계는 IKE SA 협상, Diffie-Hellman 교환 및 피어 인증입니다.) 또한 메인 모드를 사용하면 피어가 자신의 ID를 숨길 수 있습니다.

또한 적극적인 모드는 인증된 IKE(Internet Key Exchange) SA 및 키를 설정합니다. 그러나 적극적인 모드는 메시지 수의 절반을 사용하고, 협상 권한이 적으며, ID 보호를 제공하지 않습니다. 피어는 적극적인 모드 또는 기본 모드를 사용하여 IKE 협상을 시작할 수 있습니다. 원격 피어는 피어가 보낸 모드를 수락합니다.

참고:

모드 구성은 옵션이 로 설정된 경우에만 version 필요합니다.1

IKE(Internet Key Exchange) 정책의 모드를 구성하려면 문을 포함 mode 하고 aggressive 계층 수준에서 [edit services ipsec-vpn ike policy policy-name] 또는 지정 main 하십시오.

IKE 정책에는 IKE 정책과 관련된 하나 이상의 제안 목록이 포함됩니다.

IKE(Internet Key Exchange) 정책에서 제안을 구성하려면 문을 포함 proposals 하고 계층 수준에서 하나 이상의 제안 이름을 지정합니다.[edit services ipsec-vpn ike policy policy-name]

계층 수준에서 [edit services ipsec-vpn ike proposal proposal-name] 문을 포함 authentication-method pre-shared-keys 하면 IKE(Internet Key Exchange) 정책 사전 공유 키가 피어를 인증합니다. 사전 공유 키를 수동으로 구성해야 하며, 이는 피어의 키와 일치해야 합니다. 사전 공유 키는 ASCII 텍스트(영숫자) 키 또는 16진수 키일 수 있습니다.

IKE(Internet Key Exchange) 정책에서 사전 공유 키를 구성하려면 계층 수준에서 문과 키를 포함 pre-shared-key 합니다.[edit services ipsec-vpn ike policy policy-name]

키는 다음 중 하나일 수 있습니다.

• ascii-text- ASCII 텍스트 키. 이 옵션을 사용하면 des-cbc 키에 8개의 ASCII 문자가 포함됩니다. 이 옵션을 사용하면 3des-cbc 키에 24개의 ASCII 문자가 포함됩니다.

• hexadecimal—16진수 키. 이 옵션을 사용하면 des-cbc 키에 16개의 16진수가 포함됩니다. 이 옵션을 사용하면 3des-cbc 키에 48개의 16진수가 포함됩니다.

IKE(Internet Key Exchange) 정책에 대한 선택적 텍스트 설명을 지정하려면 계층 수준에서 문을 포함 description 합니다.[edit services ipsec-vpn ike policy policy-name

IKE(Internet Key Exchange) 1단계 협상에 사용할 로컬 식별자를 선택적으로 지정할 수 있습니다. local-id 이 문을 생략하면 로컬 게이트웨이 주소가 사용됩니다.

Junos OS 릴리스 19.1R1부터 로컬 ID 유형 중 하나를 고유 이름으로 구성할 수 있으며 원격 ID 유형 중 하나를 고유 이름으로 구성할 수 있습니다. 고유 이름 필드는 컨테이너 문자열 값이 있는 컨테이너 또는 와일드카드 문자열 값이 있는 와일드카드일 수 있습니다.

고유 이름은 사용자를 고유하게 식별하기 위해 디지털 인증서와 함께 사용되는 이름입니다. 예를 들어 고유 이름은 다음과 같습니다.

• CN=사용자

• DC=예

• DC=com

컨테이너 문자열의 경우, 필드 순서와 해당 값은 피어의 디지털 인증서에 있는 고유 이름과 정확히 일치해야 합니다. 예: container ["C=US, ST=CA, L=Sunnyvale, O=Juniper, CN=local_neg, CN=test@juniper.net, OU=QA" "cn=admin, ou=eng, o=example, dc=net" ];

와일드카드 문자열의 경우, 구성된 필드 및 값은 피어의 디지털 인증서에 있는 고유 이름과 일치해야 하지만 DN의 필드 순서는 중요하지 않습니다. 예: wildcard [ "L=Sunnyvale, O=Juniper" "C=US, ST=CA" ];

하나 이상의 로컬 ID를 지정하려면 계층 수준에서 [edit services ipsec-vpn ike policy policy-name] 문을 포함 local-id 합니다.

또한 IKE(Internet Key Exchange) 정책이 사용되는 원격 게이트웨이 식별자를 지정할 수 있습니다. 이 정책이 정의된 원격 게이트웨이 주소가 기본적으로 추가됩니다.

하나 이상의 원격 ID를 지정하려면 계층 수준에서 문을 포함 remote-id 합니다.[edit services ipsec-vpn ike policy policy-name]

any-remote-id 이 옵션을 사용하면 모든 원격 주소를 연결할 수 있습니다. 이 옵션은 동적 엔드포인트 구성에서만 지원되며 특정 값과 함께 구성할 수 없습니다.

SA(Security Association)의 피어가 동기화되지 않으면 잘못된 SPI(Security Parameter Index) 값을 가진 패킷이 전송될 수 있으며 수신 피어는 이러한 패킷을 삭제합니다. 예를 들어 피어 중 하나가 재부팅될 때 이러한 문제가 발생할 수 있습니다. Junos OS 릴리스 14.2부터는 SA를 재동기화하여 유효하지 않은 SPI가 있는 패킷이 수신될 때 디바이스가 복구할 수 있도록 할 수 있습니다.

잘못된 SPI 값에서 복구를 활성화하려면 계층 수준에서 문을 포함 respond-bad-spi 합니다.[edit services ipsec-vpn ike policy] policy-name

두 개의 IKE(Internet Key Exchange) 정책 policy 10.1.1.2 및 를 정의합니다policy 10.1.1.1. 각 정책은 및 와 proposal-2관련이 있습니다.proposal-1 다음 구성은 협상에 IKEv1만 사용합니다.

참고:

현재 IKE 제안 및 정책 구성에 대한 업데이트는 현재 IKE SA에 적용되지 않습니다. 업데이트가 새 IKE(Internet Key Exchange) SA에 적용됩니다.

새 업데이트를 즉시 적용하려면 기존 IKE 보안 연결을 지워 변경된 구성으로 다시 설정되도록 해야 합니다. 현재 IKE 보안 연결을 지우는 방법에 대한 자세한 내용은 clear services ipsec-vpn ike security-associations를 참조하십시오.

IPsec 제안에 대한 인증 알고리즘을 구성하려면 계층 수준에서 문을 포함 authentication-algorithm 합니다.[edit services ipsec-vpn ipsec proposal proposal-name]

인증 알고리즘은 다음 중 하나가 될 수 있습니다.

• hmac-md5-96- 패킷 데이터를 인증하는 해시 알고리즘입니다. 128비트 다이제스트를 생성합니다. 인증에는 96비트만 사용됩니다.

• hmac-sha1-96- 패킷 데이터를 인증하는 해시 알고리즘입니다. 160비트 다이제스트를 생성합니다. 인증에는 96비트만 사용됩니다.

• hmac-sha-256-128- 패킷 데이터를 인증하는 해시 알고리즘입니다. 256비트 인증자 값을 생성합니다.

참고:

IPsec 제안에서 인증 알고리즘을 구성할 때 다음 사항을 염두에 두십시오.

• IPsec VPN 터널의 양쪽 끝에 동일한 IKE 제안이 포함되어 있지만 서로 다른 IPsec 제안이 포함된 경우 오류가 발생하고 이 시나리오에서 터널이 설정되지 않습니다. 예를 들어, 터널의 한쪽 끝에 hmac-sha- 256-128의 인증 알고리즘으로 구성된 라우터 1이 포함되어 있고 터널의 다른 쪽 끝에 hmac-md5-96의 인증 알고리즘으로 구성된 라우터 2가 포함된 경우, VPN 터널은 설정되지 않습니다.

• IPsec VPN 터널의 양쪽 끝에 동일한 IKE 제안이 포함되어 있지만 서로 다른 IPsec 제안이 포함되어 있고, 터널의 한쪽 끝에 덜 안전한 알고리즘이 선택되었는지 여부를 확인하기 위한 두 개의 IPsec 제안이 포함되어 있으면 오류가 발생하고 터널이 설정되지 않습니다. 예를 들어, 터널의 한쪽 끝인 라우터 1에서 IPsec 제안에 대한 두 개의 인증 알고리즘을 hmac-sha-256-128 및 hmac-md5-96으로 구성하고, 터널의 다른 쪽 끝인 라우터 2에서 IPsec 제안에 대한 알고리즘을 hmac-md5-96으로 구성하면 터널이 설정되지 않고 제안 수가 일치하지 않습니다.

• 터널의 양쪽 끝에 두 개의 IPsec 제안을 구성할 경우, 예를 들어 터널 중 하나에서 계층 수준에서 [edit services ipsec-vpn ipsec proposal proposal-name] 명령문인 라우터 1(순서를 지정하기 위해 두 개의 연속된 문에 알고리즘 포함) authentication-algorithm hmac-md5-96 및 터널 중 하나에서 계층 수준에 [edit services ipsec-vpn ipsec proposal proposal-name] 있는 and authentication- algorithm hmac-sha-256-128 문, 라우터 2(순서를 지정하는 두 개의 연속된 문에 알고리즘 포함)와 같은 authentication-algorithm hmac-sha-256-128 authentication- algorithm hmac-md5-96 라우터 1의 역순임)은 제안 수가 양쪽 끝에서 동일하고 동일한 알고리즘 세트를 포함하므로 예상대로 이 조합으로 터널이 설정됩니다. 그러나 선택한 인증 알고리즘은 hmac-md5-96이지 hmac-sha-256-128의 더 강력한 알고리즘이 아닙니다. 이러한 알고리즘 선택 방법은 일치하는 첫 번째 제안이 선택되었기 때문에 발생합니다. 또한 기본 제안의 경우, 라우터가 AES(Advanced Encryption Standard) 암호화 알고리즘을 지원하는지 여부와 관계없이 AES-CFB 알고리즘이 아닌 3des-cbc 알고리즘이 선택됩니다. 이는 기본 제안의 첫 번째 알고리즘이 선택되기 때문입니다. 여기에 설명된 샘플 시나리오에서 라우터 2에서 제안의 알고리즘 구성 순서를 반대로 하여 라우터 1에서 지정된 순서와 동일한 순서가 되도록 하면 hmac-sha-256-128이 인증 방법으로 선택됩니다.

• 두 피어의 두 정책 모두에 제안이 있을 때 가장 강력한 알고리즘이 먼저 고려되는 것과 같은 특정 기본 설정 순서로 제안이 이루어지기를 원한다면, 구성 시 IPsec 정책의 제안 순서를 알고 있어야 합니다.

IPsec 제안에 대한 선택적 텍스트 설명을 지정하려면 계층 수준에서 문을 포함 description 합니다.[edit services ipsec-vpn ipsec proposal proposal-name]

IPsec 제안에 대한 암호화 알고리즘을 구성하려면 계층 수준에서 문을 포함 encryption-algorithm 합니다.[edit services ipsec-vpn ipsec proposal proposal-name]

암호화 알고리즘은 다음 중 하나가 될 수 있습니다.

• 3des-cbc- 블록 크기가 24바이트인 암호화 알고리즘입니다. 키 크기는 192비트입니다.

• aes-128-cbc- 고급 암호화 표준(AES) 128비트 암호화 알고리즘.

• aes-192-cbc—고급 암호화 표준(AES) 192비트 암호화 알고리즘.

• aes-256-cbc- 고급 암호화 표준(AES) 256비트 암호화 알고리즘.

참고:

Junos FIPS 모드의 경우 AES-GCM은 Junos OS 릴리스 17.3R1에서 지원되지 않습니다. Junos OS 릴리스 17.4R1부터 AES-GCM은 Junos FIPS 모드에서 지원됩니다.

• aes-128-gcm—MS-MPC 및 MS-MIC용 Junos OS 릴리스 17.3R1부터, 16 옥텟 ICV(Integrity Check Value)를 사용하는 AES-GCM(Advanced Encryption Standard in Galois/Counter Mode) 128비트 암호화 알고리즘이 적용됩니다.

• aes-192-gcm—MS-MPC 및 MS-MIC용 Junos OS 릴리스 17.3R1부터, 16옥텟 무결성 검사 값 ICV를 사용하는 AES-GCM(Advanced Encryption Standard in Galois/Counter Mode) 192비트 암호화 알고리즘이 적용됩니다.

• aes-256-gcm—MS-MPC 및 MS-MIC용 Junos OS 릴리스 17.3R1부터, 16옥텟 무결성 검사 값 ICV를 사용하는 AES-GCM(Advanced Encryption Standard in Galois/Counter Mode) 256비트 암호화 알고리즘이 적용됩니다.

• des-cbc- 블록 크기가 8바이트인 암호화 알고리즘입니다. 키 크기는 48비트입니다.

참고:

DES(Data Encryption Standard) 암호화 알고리즘의 약한 키와 반약한 키의 목록은 RFC 2409, The Internet Key Exchange(IKE)를 참조하십시오. AES 암호화 알고리즘은 처리량이 훨씬 낮은 소프트웨어 구현을 사용하므로 DES가 여전히 권장되는 옵션입니다.

의 경우 3des-cbc처음 8바이트는 두 번째 8바이트와 달라야 하며 두 번째 8바이트는 세 번째 8바이트와 동일해야 합니다.

특정 인증 또는 암호화 설정을 구성하지 않으면 Junos OS는 인증 및 3des-cbc 암호화에 대한 기본값을 사용합니다sha1. NULL 암호화가 유효하려면 다른 시스템 구성에 관계없이 계층 수준에서 [edit services ipsec-vpn ipsec proposal proposal-name] 문을 포함하여 protocol esp 항상 NULL 암호화 알고리즘에 대한 ESP(Encapsulating 보안 페이로드) 프로토콜을 지정해야 합니다.

동적 IPsec SA가 생성되면 하드 및 소프트의 두 가지 유형의 수명이 사용됩니다. 하드 수명은 SA의 수명을 지정합니다. 하드 수명에서 파생되는 소프트 수명은 SA가 곧 만료될 것임을 IPsec 키 관리 시스템에 알립니다. 이를 통해 키 관리 시스템은 하드 수명이 만료되기 전에 새 SA를 협상할 수 있습니다.

참고:

IKEv1에서 SA의 수명은 IPsec 제안에 구성된 수명 유형에 따라 원격 피어와 협상됩니다. IKEv2에서는 이러한 협상이 원격 피어와 수행되지 않습니다. 대신 각 IKE(Internet Key Exchange) 피어는 로컬로 구성된 수명을 사용합니다.

IKEv2의 SA의 경우, 수명은 IKEv1의 기본값(IPsec 제안에 다른 수명이 구성되지 않은 경우)이거나 IPsec 정책의 모든 IKEv2 제안이 동일한 수명 값으로 구성되어야 합니다.

하드 수명 값을 구성하려면 문을 포함 lifetime-seconds 하고 계층 수준에서 초 수를 지정합니다.[edit services ipsec-vpn ipsec proposal proposal-name]

기본 수명은 28,800초입니다. 범위는 180초에서 86,400초입니다.

소프트 수명을 계산하기 위해 처음에는 lifetime-diff가 계산됩니다. 그런 다음 피어가 개시자인지 응답자인지에 따라 소프트 수명이 계산됩니다.

수명 차이 계산은 다음과 같이 수행됩니다.

• (3*hard-lifetime)/10이 850초보다 큰 경우, lifetime-diff = 850초 + 0에서 850초 사이의 지터입니다.

  참고:

  지터 값은 모든 IPsec SA 설치 시 0에서 850으로 증가하고 0으로 재설정됩니다.

• (3*hard-lifetime)/10이 600초보다 크고 850보다 작으면 lifetime-diff = 600초 + 0에서 45초 사이의 임의 지터입니다.

• (3*hard-lifetime)/10이 90초보다 크고 600보다 작으면 lifetime-diff = 90초 + 0에서 45초 사이의 임의 지터입니다.

• (3*hard-lifetime)/10이 90초 미만인 경우, lifetime-diff = 90초 + 0초에서 10초 사이의 임의 지터입니다.

수명 차이를 기준으로 소프트 수명은 다음과 같이 계산됩니다.

• lifetime-diff가 hard-lifetime보다 크면 soft lifetime = (9*hard-lifetime)/10

• 개시자 소프트 수명 = 하드 수명 - 수명 차이

• 응답자 소프트 수명 = 하드 수명 - 수명 차이 + 45초

참고:

개시자 소프트 수명은 항상 응답자 소프트 수명보다 짧습니다. 이는 키 재입력 프로세스를 시작할 수 있도록 개시자 소프트 수명이 먼저 만료되도록 하기 위한 것입니다.

예를 들어, IPSec SA의 하드 수명이 3,600초로 구성된 경우:

• 이니시에이터의 최대 소프트 수명: 3600 - 850(지터는 0과 같음) = 2750초

• 개시자의 최소 소프트 수명: 3600 - 850 - 850(지터는 850과 같음) = 1900초

• 응답자의 최대 소프트 수명: 3600 - 850(지터는 0과 같음) + 45 = 2795초

• 응답자의 최소 소프트 수명: 3600 - 850 - 850(지터는 850과 같음) + 45 = 1945초

문은 protocol 동적 SA에 대한 프로토콜을 설정합니다. IPsec은 ESP와 AH의 두 가지 프로토콜을 사용하여 IP 트래픽을 보호합니다. ESP 프로토콜은 인증, 암호화 또는 둘 다를 지원할 수 있습니다. AH 프로토콜은 강력한 인증에 사용됩니다. AH는 또한 IP 패킷을 인증합니다. 이 bundle 옵션은 AH 인증과 ESP 암호화를 사용합니다. AH가 IP 패킷에 대한 더 강력한 인증을 제공하기 때문에 ESP 인증은 사용하지 않습니다.

동적 SA에 대한 프로토콜을 구성하려면 문을 포함 protocol 하고 계층 수준에서 , esp, 또는 bundle 옵션을 지정합니다ah.[edit services ipsec-vpn ipsec proposal proposal-name]

IPsec 정책에 대한 선택적 텍스트 설명을 지정하려면 계층 수준에서 문을 포함 description 합니다.[edit services ipsec-vpn ipsec policy policy-name]

PFS(Perfect Forward Secrecy)는 Diffie-Hellman 공유 비밀 값을 통해 추가 보안을 제공합니다. PFS를 사용하면 하나의 키가 손상되더라도 이전 키와 후속 키는 이전 키에서 파생되지 않기 때문에 안전합니다. 이 문은 선택 사항입니다.

PFS를 구성하려면 문을 포함 perfect-forward-secrecy 하고 계층 수준에서 Diffie-Hellman 그룹을 지정합니다.[edit services ipsec-vpn ipsec policy policy-name]

키는 다음 중 하나일 수 있습니다.

• group1- 새로운 Diffie-Hellman 교환을 수행할 때 IKE가 768비트 Diffie-Hellman 기본 모듈러스 그룹을 사용하도록 지정합니다.

• group2- 새로운 Diffie-Hellman 교환을 수행할 때 IKE가 1024비트 Diffie-Hellman 프라임 모듈러스 그룹을 사용하도록 지정합니다.

• group5- 새로운 Diffie-Hellman 교환을 수행할 때 IKE가 1536비트 Diffie-Hellman 기본 모듈러스 그룹을 사용하도록 지정합니다.

• group14- 새로운 Diffie-Hellman 교환을 수행할 때 IKE가 2048비트 Diffie-Hellman 소수 모듈러스 그룹을 사용하도록 지정합니다.

Junos OS 릴리스 17.4R1부터 group15, group16 및 group 24도 다음 키에 사용할 수 있습니다.

• group15- 새로운 Diffie-Hellman 교환을 수행할 때 IKE가 3072비트 Diffie-Hellman 기본 모듈러스 그룹을 사용하도록 지정합니다.

• group16- 새로운 Diffie-Hellman 교환을 수행할 때 IKE가 4096비트 Diffie-Hellman 소수 모듈러스 그룹을 사용하도록 지정합니다.

• group24- IKE가 새로운 Diffie-Hellman 교환을 수행할 때 256비트 프라임 오더 하위 그룹과 함께 2048비트 Diffie-Hellman 프라임 모듈러스 그룹을 사용하도록 지정합니다.

번호가 높은 그룹은 번호가 낮은 그룹보다 더 많은 보안을 제공하지만 더 많은 처리 시간이 필요합니다.

IPsec 정책에는 IPsec 정책과 관련된 하나 이상의 제안 목록이 포함됩니다.

IPsec 정책에서 제안을 구성하려면 문을 포함 proposals 하고 계층 수준에서 하나 이상의 제안 이름을 지정합니다.[edit services ipsec-vpn ipsec policy policy-name]

동적 엔드포인트에 대한 IPsec 정책은 터널의 원격 끝에 정적으로 할당된 IP 주소가 없는 동적 피어 보안 게이트웨이 간의 IPsec 협상 중에 사용되는 보안 매개 변수(IPsec 제안)의 조합을 정의합니다. IPsec 협상 중에 IPsec 정책은 두 피어에서 동일한 IPsec 제안을 찾습니다. 협상을 시작하는 피어는 모든 정책을 원격 피어에 전송하고 원격 피어는 일치하는 정책을 찾으려고 시도합니다. 두 피어의 정책에 동일한 구성 속성을 포함하는 제안이 있을 때 일치가 이루어집니다. 수명이 동일하지 않은 경우, 두 정책(호스트와 피어로부터) 사이의 더 짧은 수명이 사용됩니다.

정책이 설정되지 않은 경우 동적 피어가 제안한 모든 정책이 수락됩니다.

두 개의 제안(dynamic-1 및 dynamic-2)과 연결된 IPsec 정책을 dynamic policy-1정의합니다.

참고:

현재 IPsec 제안 및 정책 구성에 대한 업데이트는 현재 IPsec SA에 적용되지 않습니다. 업데이트는 새 IPsec SA에 적용됩니다.

새 업데이트를 즉시 적용하려면 기존 IPsec 보안 연결을 지워 변경된 구성으로 다시 설정되도록 해야 합니다. 현재 IPsec 보안 연결을 지우는 방법에 대한 자세한 내용은 Junos OS 시스템 기본 사항 및 서비스 명령 참조 를 참조하십시오.