IPsec 개요
보안 연결 개요
IPsec 보안 서비스를 사용하려면 호스트 간에 SA를 생성합니다. SA는 두 호스트가 IPsec을 통해 서로 안전하게 통신할 수 있도록 하는 단순 연결입니다. SA에는 수동 및 동적의 두 가지 유형이 있습니다.
수동 SA는 협상이 필요하지 않습니다. 키를 포함한 모든 값은 정적이며 구성에 지정됩니다. 수동 SA는 사용할 SPI(Security Parameter Index) 값, 알고리즘 및 키를 정적으로 정의하며 터널 양쪽 끝에서 일치하는 구성이 필요합니다. 통신을 수행하려면 각 피어에 동일한 구성 옵션이 있어야 합니다.
동적 SA에는 추가 구성이 필요합니다. 동적 SA를 사용하면 먼저 IKE(Internet Key Exchange )를 구성한 다음 SA를 구성합니다. IKE는 동적 보안 연결을 생성합니다. IPsec을 위해 SA를 협상합니다. IKE 구성은 피어 보안 게이트웨이와의 보안 IKE 연결을 설정하는 데 사용되는 알고리즘과 키를 정의합니다. 그런 다음 이 연결은 동적 IPsec SA에서 사용하는 키 및 기타 데이터에 동적으로 동의하는 데 사용됩니다. IKE(Internet Key Exchange) SA가 먼저 협상된 다음 동적 IPsec SA를 결정하는 협상을 보호하는 데 사용됩니다.
터널 속성 협상 및 키 관리를 포함하여 사용자 수준 터널 또는 SA를 설정합니다. 이러한 터널은 동일한 보안 채널 위에서 새로 고침 및 종료할 수도 있습니다.
IPsec의 Junos OS 구현은 두 가지 보안 모드(전송 모드 및 터널 모드)를 지원합니다.
또한보십시오
IKE(Internet Key Management Protocol) 개요
IKE(Internet Key Exchange)는 동적 SA를 생성하는 키 관리 프로토콜입니다. IPsec을 위해 SA를 협상합니다. IKE(Internet Key Exchange) 구성은 피어 보안 게이트웨이와의 보안 연결을 설정하는 데 사용되는 알고리즘과 키를 정의합니다.
IKE(Internet Key Exchange)는 다음을 수행합니다.
IKE 및 IPsec 매개 변수 협상 및 관리
보안 키 교환 인증
공유 암호(비밀번호가 아님) 및 공개 키를 통해 상호 피어 인증 제공
ID 보호 제공(기본 모드)
IKE(Internet Key Exchange)는 두 단계에 걸쳐 발생합니다. 첫 번째 단계에서는 보안 속성을 협상하고 공유 암호를 설정하여 양방향 IKE(Internet Key Exchange) SA를 구성합니다. 두 번째 단계에서는 인바운드 및 아웃바운드 IPsec SA가 설정됩니다. IKE(Internet Key Exchange) SA는 두 번째 단계에서 거래소를 보호합니다. 또한 IKE는 키 자료를 생성하고, PFS(Perfect Forward Secrecy)를 제공하며, ID를 교환합니다.
Junos OS 릴리스 14.2부터 jnxIkeTunnelTable 테이블에서 Request failed: OID not increasing
jnxIkeTunnelEntry 객체의 SNMP 워크를 수행하면 오류 메시지가 생성될 수 있습니다. 이 문제는 SA의 양쪽 끝이 동시에 IKE SA 협상을 시작할 때 발생하는 동시 IKE SA(Internet Key Exchange 보안 연결)를 만들 때만 발생합니다. IKE(Internet Key Exchange) SA를 표시하기 위해 SNMP 관리 정보 베이스(MIB) 워크가 수행되면 snmpwalk 도구는 개체 식별자(OID)가 오름차순일 것으로 예상합니다. 그러나 동시 IKE SA의 경우 SNMP 테이블의 OID 순서가 증가하지 않을 수 있습니다. 이 동작은 OID의 일부인 터널 ID가 IKE 터널의 양쪽에 있을 수 있는 IKE(Internet Key Exchange) SA의 개시자를 기반으로 할당되기 때문에 발생합니다.
다음은 IKE 동시 SA에서 수행되는 SNMP 관리 정보 베이스(MIB) 워크의 예입니다.
jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47885 = INTEGER: responder(2) >>> This is Initiator SA jnxIkeTunLocalRole."ipsec_ss_cust554".ipv4."192.0.2.41".47392 = INTEGER: initiator(1) >>> This is Responder's SA
SNMP 워크가 터널 ID(47885 및 47392)인 경우 OID 비교가 실패합니다. SNMP 워크가 수행될 때 터널이 어느 쪽에서든 시작될 수 있기 때문에 터널 ID의 순서가 증가하고 있는지 확인할 수 없습니다.
이 문제를 해결하기 위해 SNMP 관리 정보 베이스(MIB) walk에는 증가하는 OID에 대한 확인을 비활성화하는 옵션 -Cc가 포함되어 있습니다. 다음은 -Cc 옵션을 사용하여 jnxIkeTunnelEntry 테이블에서 수행된 관리 정보 베이스(MIB) 워크의 예입니다.
snmpwalk -Os -Cc -c public -v 1 vira jnxIkeTunnelEntry
또한보십시오
Junos-FIPS를 위한 IPsec 요구 사항
Junos-FIPS 환경에서는 라우팅 엔진 간의 모든 통신에 IPsec과 프라이빗 라우팅 인스턴스를 사용하도록 두 개의 라우팅 엔진을갖춘 하드웨어 구성을 구성해야 합니다. 라우팅 엔진과 AS II FIPS PIC간의 IPsec 통신도 필요합니다.
또한보십시오
IPsec 개요
IPsec(IP Security)은 IP 네트워크를 통한 안전한 개인 통신을 보장하기 위한 표준 기반 프레임워크입니다. IPsec은 보낸 사람을 인증하고 라우터 및 호스트와 같은 네트워크 디바이스 간의 IP 버전 4(IPv4) 및 버전 6(IPv6) 트래픽을 암호화하는 안전한 방법을 제공합니다. IPsec에는 데이터 무결성, 보낸 사람 인증, 원본 데이터 기밀성 및 데이터 재생에 대한 보호가 포함됩니다.
이해해야 할 주요 개념은 다음과 같습니다.
IPsec 지원 라인 카드
Junos OS 기반 라우터에서 IPsec을 구현할 때 가장 먼저 선택해야 할 것은 사용하려는 라인 카드 유형입니다. 라인 카드라는 용어에는 PIC(Physical Interface Card), MIC(Modular Interface Card), DPC(Dense Port Concentrator) 및 MPC(Modular Port Concentrator)가 포함됩니다. IPsec 구현을 지원하는 라인 카드는 다음과 같습니다.
라우터의 라인 카드가 IPsec을 지원하는지 확인하려면 라우터에 대한 특정 하드웨어 설명서를 참조하십시오.
IPsec을 지원하는 라인 카드는 다음과 같습니다.
암호화 서비스(ES) PIC는 IPsec을 위한 암호화 서비스 및 소프트웨어 지원을 제공합니다.
적응형 서비스(AS) PIC 및 적응형 서비스(AS) II PIC는 IPsec 서비스 및 네트워크 주소 변환(NAT) 및 스테이트풀 방화벽과 같은 기타 서비스를 제공합니다.
AS II FIPS(Federal Information Processing Standards) PIC는 내부 IPsec을 사용하여 라우팅 엔진과 안전하게 통신하는 AS PIC의 특수 버전입니다. 라우터에서 FIPS 모드를 활성화할 때 AS II FIPS PIC에서 IPsec을 구성해야 합니다. FIPS 모드로 구성된 라우터에 설치된 AS II FIPS PIC에서 IPsec을 구현하는 방법에 대한 자세한 내용은 공통 기준 및 Junos-FIPS에 대한 보안 구성 가이드를 참조하십시오.
멀티서비스 PIC는 패킷 처리 집약적인 서비스 어레이에 대한 하드웨어 가속화를 제공합니다. 이러한 서비스에는 IPsec 서비스 및 스테이트풀 방화벽, NAT, IPsec, 이상 탐지 및 터널 서비스와 같은 기타 서비스가 포함됩니다.
Multiservices DPC(Dense Port Concentrator)는 IPsec 서비스를 제공합니다.
MS-MPC(Multiservices Modular Port Concentrator)는 IPsec 서비스를 지원합니다.
MS-MIC(Multiservices Modular Interface Card)는 IPsec 서비스를 지원합니다.
IPsec 서비스 패키지를 포함한 Junos OS 확장 공급자 패키지는 MS-MPC 및 MS-MIC에 사전 설치 및 구성되어 제공됩니다.
또한보십시오
인증 알고리즘
인증은 보낸 사람의 ID를 확인하는 프로세스입니다. 인증 알고리즘은 공유 키를 사용하여 IPsec 디바이스의 신뢰성을 확인합니다. Junos OS는 다음과 같은 인증 알고리즘을 사용합니다.
MD5(Message Digest 5)는 단방향 해시 함수를 사용하여 임의 길이의 메시지를 128비트의 고정 길이 메시지 다이제스트로 변환합니다. 변환 프로세스로 인해 결과 메시지 다이제스트에서 거꾸로 계산하여 원본 메시지를 계산하는 것은 수학적으로 불가능합니다. 마찬가지로 메시지에서 단일 문자가 변경되면 매우 다른 메시지 다이제스트 번호가 생성됩니다.
메시지가 변조되지 않았는지 확인하기 위해 Junos OS는 계산된 메시지 다이제스트를 공유 키로 복호화된 메시지 다이제스트와 비교합니다. Junos OS는 추가적인 수준의 해싱을 제공하는 MD5 HMAC(Hashed Message Authentication Code) 변형을 사용합니다. MD5는 인증 헤더(AH), 캡슐화 보안 페이로드(ESP) 및 인터넷 키 교환(IKE)과 함께 사용할 수 있습니다.
보안 해시 알고리즘 1(SHA-1)은 MD5보다 더 강력한 알고리즘을 사용합니다. SHA-1은 길이가 264비트 미만인 메시지를 사용하여 160비트 메시지 다이제스트를 생성합니다. 큰 메시지 다이제스트는 데이터가 변경되지 않았으며 올바른 소스에서 시작되었는지 확인합니다. Junos OS는 추가적인 수준의 해싱을 제공하는 SHA-1 HMAC 변형을 사용합니다. SHA-1은 AH, ESP 및 IKE와 함께 사용할 수 있습니다.
SHA-256, SHA-384 및 SHA-512(SHA-2라는 이름으로 그룹화되기도 함)는 SHA-1의 변형이며 더 긴 메시지 다이제스트를 사용합니다. Junos OS는 모든 버전의 AES(Advanced Encryption Standard), DES(Data Encryption Standard) 및 3DES(Triple DES) 암호화를 처리할 수 있는 SHA-256 버전의 SHA-2를 지원합니다.
암호화 알고리즘
암호화는 권한이 없는 사용자가 해독할 수 없도록 데이터를 안전한 형식으로 인코딩합니다. 인증 알고리즘과 마찬가지로 공유 키는 암호화 알고리즘과 함께 사용되어 IPsec 디바이스의 신뢰성을 검증합니다. Junos OS는 다음과 같은 암호화 알고리즘을 사용합니다.
DES-CBC(Data Encryption Standard Cipher-Block Chaining)는 대칭 비밀 키 블록 알고리즘입니다. DES는 64비트의 키 크기를 사용하며, 여기서 8비트는 오류 검색에 사용되고 나머지 56비트는 암호화를 제공합니다. DES는 공유 키에 대해 순열 및 대체를 비롯한 일련의 간단한 논리 연산을 수행합니다. CBC는 DES에서 64비트 출력의 첫 번째 블록을 가져와서 이 블록을 두 번째 블록과 결합하고, 이를 DES 알고리즘에 다시 피드백하고, 모든 후속 블록에 대해 이 프로세스를 반복합니다.
3DES-CBC(Triple DES-CBC)는 DES-CBC와 유사하지만 168비트(3 x 56비트) 암호화에 3개의 키를 사용하므로 훨씬 더 강력한 암호화 결과를 제공하는 암호화 알고리즘입니다. 3DES는 첫 번째 키를 사용하여 블록을 암호화하고, 두 번째 키를 사용하여 블록을 해독하고, 세 번째 키를 사용하여 블록을 다시 암호화하는 방식으로 작동합니다.
AES(Advanced Encryption Standard)는 벨기에의 암호학자인 Joan Daemen 박사와 Vincent Rijmen 박사가 개발한 Rijndael 알고리즘을 기반으로 하는 차세대 암호화 방법입니다. 128비트 블록과 세 가지 키 크기(128비트, 192비트 및 256비트)를 사용합니다. 키 크기에 따라 알고리즘은 바이트 대체, 열 혼합, 행 이동 및 키 추가를 포함하는 일련의 계산(10, 12 또는 14라운드)을 수행합니다. AES와 IPsec의 사용은 RFC 3602, AES-CBC 암호 알고리즘 및 IPsec에서의 사용에 정의되어 있습니다.
Junos OS 릴리스 17.3R1부터 MS-MPC 및 MS-MIC에 대해 AES-GCM(Advanced Encryption Standard in Galois/Counter Mode)이 지원됩니다. 그러나 Junos FIPS 모드에서는 Junos OS 릴리스 17.3R1에서 AES-GCM이 지원되지 않습니다. Junos OS 릴리스 17.4R1부터 AES-GCM은 Junos FIPS 모드에서 지원됩니다. AES-GCM은 인증과 개인 정보 보호를 모두 제공하도록 설계된 인증된 암호화 알고리즘입니다. AES-GCM은 이진 Galois 필드에 대한 범용 해싱을 사용하여 인증된 암호화를 제공하고 수십 Gbps의 데이터 속도로 인증된 암호화를 허용합니다.
또한보십시오
IPsec 프로토콜
IPsec 프로토콜은 라우터에 의해 보호되는 패킷에 적용되는 인증 및 암호화 유형을 결정합니다. Junos OS는 다음과 같은 IPsec 프로토콜을 지원합니다.
AH - RFC 2402에 정의된 AH는 IPv4 및 IPv6 패킷에 대한 무연결 무결성 및 데이터 원본 인증을 제공합니다. 또한 재생에 대한 보호 기능도 제공합니다. AH는 가능한 한 많은 IP 헤더와 상위 프로토콜 데이터를 인증합니다. 그러나 일부 IP 헤더 필드는 전송 중에 변경될 수 있습니다. 이러한 필드의 값은 보낸 사람이 예측할 수 없기 때문에 AH로 보호할 수 없습니다. IP 헤더에서 AH는 IPv4 패킷의 필드와
Next Header
IPv6 패킷의 필드의 값으로51
Protocol
식별될 수 있습니다. AH가 제공하는 IPsec 보호의 예는 그림 1에 나와 있습니다.메모:AH는 T 시리즈, M120 및 M320 라우터에서 지원되지 않습니다.

ESP—RFC 2406에 정의된 ESP는 암호화 및 제한된 트래픽 흐름 기밀성 또는 무연결 무결성, 데이터 원본 인증 및 안티리플레이 서비스를 제공할 수 있습니다. IP 헤더에서 ESP는 IPv4 패킷의 필드와
Next Header
IPv6 패킷의 필드에서Protocol
값을50
식별할 수 있습니다. ESP에서 제공하는 IPsec 보호의 예는 그림 2에 나와 있습니다.

번들 - AH와 ESP를 비교할 때 두 프로토콜 모두에 몇 가지 장점과 단점이 있습니다. ESP는 적절한 수준의 인증 및 암호화를 제공하지만 IP 패킷의 일부에만 해당됩니다. 반대로, AH는 암호화를 제공하지 않지만 전체 IP 패킷에 대한 인증을 제공합니다. 이 때문에 Junos OS는 프로토콜 번들이라는 세 번째 형태의 IPsec 프로토콜을 제공합니다. 번들 옵션은 AH 인증과 ESP 암호화의 하이브리드 조합을 제공합니다.
또한보십시오
변경 내역 테이블
기능 지원은 사용 중인 플랫폼 및 릴리스에 따라 결정됩니다. 기능 탐색기 를 사용하여 플랫폼에서 기능이 지원되는지 확인합니다.
Request failed: OID not increasing
jnxIkeTunnelEntry 객체의 SNMP 워크를 수행하면 오류 메시지가 생성될 수 있습니다.