IPsec 표준화 동향 및 제품 현황

정지훈* 이종태** 손승원***

본 문서에서는 최근 관심이 집중되고 있는 인터넷 정보보호 분야의 표준인 IPsec 기술의 표준화 동향과 현재 구현된 IPsec 제품군의 현황을 설명하고 있다. IPsec 제품군이라 함은 IPsec을 지원하는 라우터, 호스트, 게이트웨이, VPN 서버, 방화벽 및 IPsec을 지원하는 제품들을 제어하고 통제하는 소프트웨어를 포함하고 있다. IPsec 관련 제품들은 ICSA(http://www.isca.net)를 통해 관련 제품 인증을 해주고 있다. 본 문서에서 언급한 대부분의 IPsec 제품군은 이미 ISCA에서 인증을 받은 제품들이다. ▒

I. 서 론

최근 인터넷 사용 인구의 급격한 증가와 인터넷 서비스의 대중적 보급으로 인하여 인터넷의 성장이 점차 가속화되고 있다. 또한, 21세기 정보화 시대에 있어 인터넷은 정보와 통신이 결합되어 움직이는 명실상부한 정보화 사회 기반 구조가 될 것으로 믿어지고 있다. 이러한 인터넷의 대중적 보급과 정보 서비스의 확대로 인하여 모든 사람들이 쉽게 정보를 주고받거나 얻을 수 있게 되었음에도 불구하고 바이러스, 해킹과 같은 사이버 테러로 인하여 개인의 사생활 정보 유출은 물론 국가적 안보의 위협까지 초래되고 있다.

이러한 정보화의 역기능에 대처하고, 인터넷 통신상의 비밀 보장 및 정보보호를 위하여 1992년 11월 IETF(Internet Engineering Task Force)의 구성원들이 네트워크 계층의 프로토콜인 IP(Internet Protocol)를 사용하면서 대규모의 인터넷 환경에 적합한 보안 프로토콜의 설계를 시작했다. 이러한 계기로 구현된 시험용 프로토콜인 swIPe[1]가 탄생하였으며, 이 프로토콜이 비록 널리 통용될 만한 것은 아니었으나 설계 초기에 내세운 개념에 의한 보안 프로토콜의 구현이 가능하다는 것을 증명하는 계기가 되었다.

몇 년 후 IETF IPsec WG(Working Group)에서 요구 사항에 대한 정리가 시작되었고, 1995년 12월 Dallas에서 개최된 34차 IETF Meeting에서는 Proposed Standard로 이미 확정된 IPsec문서를 기반으로 다수의 장비 업체 및 개인들에 의해 구현된 IPsec 시스템들간의 상호 운용성 시험이 최초로 진행되었다. 또한 IPsec은 IPv6 워킹 그룹에 의해 채택되었으며, 차세대 인터넷 프로토콜에 강제 요구 사항으로 자리잡았다. 그 후 IPsec 보안 구조, 트랜스폼(Transform) 알고리즘, AH(Authentication Header), ESP(Encapsulating Security Payload) 등이 RFC(Request For Comments)로 확정되었으며, 점차 새로운 RFCs와 Internet Drafts가 만들어지고 있다[2,3,4,5,6,7].

II. IPsec 기술

IPsec에서 보안 서비스 제공을 위한 프로토콜은 AH와 ESP가 있다. AH와 ESP는 IPv6와 IPsec(IPv4)에 새로 추가된 IP 헤더로서 인터넷 보안 서비스를 실현하기 위한 노력의 결과이다. IP 패킷은 헤더와 페이로드 두 부분으로 나눌 수 있고, IP 헤더의 내용에 대한 보안 서비스를 적용하기 위하여 AH 헤더를 IP 확장 헤더로 추가하고 IP 페이로드의 내용에 대한 보안 서비스를 적용시키기 위하여 사용자 데이터를 ESP로 encapsulation한 후 헤더에 추가한다.

다음 <표 1>에서 보이는 바와 같이 AH는 접근 제어(Access Control), 비연결형 무결성(Connectionless Integrity), IP 데이터그램에 대한 데이터 발신 인증(Data Origin Authenti-cation) 등의 보안 서비스를 제공하며, 선택적으로 재전송 공격 방지(Anti-Replay) 서비스를 제공할 수 있다. 재전송 공격 방지 서비스의 경우는 디폴트로 송신측에서 순차 번호(Sequence Number)를 증가시키지만, 수신측에서 이를 검사하지 않으면 성립되지 않는 서비스로 수신측의 선택 사항으로 되어 있다. 또한, AH는 IP 헤더의 변경되지 않는 필드(Immutable Field)에 대해서만 보안 서비스를 제공한다. 따라서 통신로 상의 네트워크 장비에 의해서 변경되는 필드의 정보에 대해서는 초기 값을 0으로 둔 다음 ICV(Integrity Check Value) 계산에 의해서 필드 값의 무결성을 검사한다. ESP 헤더는 페이로드에 대해서 AH가 제공하는 서비스 외에 추가적으로 비밀성(Confidentiality) 서비스를 제공한다. 트랜스포트 모드(Transport Mode)에서는 TCP/UDP 헤더와 사용자 데이터 전체를 암호화하며, 터널 모드(Tunnel Mode)에서는 사용자측으로부터 발생된 패킷 전체를 암호화할 수 있다.

IPsec의 두 가지 프로토콜(AH, ESP)은 각 프로토콜 내부에서 사용하는 암호화 및 인증 등의 알고리즘과 무관한 구조를 가지고 있으며, IP 계층에서 사용하는 프로토콜 이외의 다른 보안 메커니즘을 필요치 않다. 이와 같이 IPsec은 프로토콜 내부에서 사용하는 알고리즘과 독립적인 구조를 가지고 있으며, 모듈성(Modularity)을 만족하도록 설계되어 있다. 또한, 프로토콜 내부에서 사용하는 알고리즘들의 표준화 작업을 통해서 인터넷 사용자간의 호환성을 제공하도록 노력을 기울이고 있다.

IPsec은 인터넷에서의 보안 기술을 제공하지만, 구현 환경 조건에 따라 성능이 달라질 수 있다. 운영 체제, 난수 발생기의 성능, 시스템 관리 프로토콜의 효율 및 구현 형태에 따라 매우 다양한 성능의 차이를 보일 수 있다. 이러한 실제 구현 환경 조성에 관한 문제들은 IPsec의 표준화 범위에 들어있지 않지만, IPsec의 실용화에 미치는 영향은 매우 크다고 할 수 있다

1. AH(Authentication Header)

가. AH 프로토콜 헤더

(그림 1)은 AH 프로토콜 헤더 구조이다. Next Header는 AH 다음에 나타날 헤더 또는 페이로드의 형태를 지정하는 8비트 필드로 IANA(Internet Assigned Numbers Authority)에서 지정한 값을 사용한다. Payload Length는 4바이트 단위로 계산되며 실제 크기에서 2를 뺀 값이 저장된다. 일반적으로 4 값을 가지며, 디버깅을 위한 null 인증을 사용할 때 IPv4의 경우는 1, IPv6의 경우는 2가 된다. Reserved 필드는 항상 0 값을 갖는다. SPI(Security Payload Index) 필드는 32비트로 유일한 SA를 식별하는데 사용되는 인자 중 하나이다. SA를 구분하는데 사용하는 인자는 {SPI, AH, 목적지주소}이다. Sequence Number 필드는 unsigned 32비트 값으로 SA가 설정될 때 송수신측에서 모두 0으로 셋팅된다. 그 후 전송시마다 송신측에서는 그 값을 1씩 증가시키고 수신측에서는 이 값을 검사하여 재전송 공격(Replay Attack)을 검사한다. 수신측에서 이 값을 검사함으로써 재전송 방지 서비스(Anti-Replay)가 성립된다. Authentication Data 필드는 4바이트의 정수배 크기로 ICV(Integrity Check Value) 값을 의미한다. 뒷부분에 패딩이 추가되면서 AH 크기가 IPv4에서는 32비트의 정수배, IPv6에서는 64비트의 정수배가 된다.

나. AH 프로토콜 처리

AH 프로토콜은 트랜스포드(Transport Mode)와 터널 모드(Tunnel Mode) 두 가지의 운용 모드를 가지고 있다. 트랜스포드 모드는 일반적으로 보안 호스트 구현시 사용되며 상위 계층 프로토콜에 대한 보호 서비스를 제공한다. 터널 모드의 경우는 보안 호스트 및 게이트웨이 구현시 모두 적용되며 outer IP 헤더를 새로이 생성하여 inner IP 헤더를 포함한 inner IP 패킷 전체에 대한 보호 서비스를 제공한다.

패킷을 송신하는 단계인 Outbound 패킷 처리 과정 및 수신 단계인 Inbound 패킷 처리 과정은 다음 (그림 2)와 같은 순서로 이루어 진다.

패킷을 송신하는 단계인 Outbound 패킷 처리 과정에서는 먼저 SA가 설정되어 있는지 SAD를 찾는다. 만약 설정된 SA가 없으면 정책에 따라 새로운 SA를 설정하고, 이미 설정된 SA가 있으면 재전송 공격 방지 서비스를 위하여 SN(Sequence Number)을 생성한다. 이때 SN 값은 초기값인 0으로 설정한다. 다음으로 전송 중 변하지 않거나 수신측에서 예측 가능한 필드 값을 이용하여 ICV를 계산하고, 패딩을 추가한 후 전송할 패킷 단위로 분할한 후 패킷을 전송한다.

패킷을 수신하는 단계인 Inbound 패킷 처리 과정은 송신 단계의 역순과 유사한 처리를 한다. 먼저 수신된 패킷을 조합한 후 AH 헤더의 {SPI, AH, 목적지주소}를 이용하여 관련 SA를 찾는다. 만약 설정된 SA가 없는 경우는 해당 패킷을 폐기하게 된다. 이미 설정된 SA가 있는 경우는 Sliding Receive Window와 Bit Masking 방법을 이용하여 SN과 ICV에 대한 검증을 수행한다. ICV 검증 단계에서 수신 패킷 내의 ICV 값이 AH 내의 값과 일치하면 통과시키고, 그렇지 않으면 해당 패킷을 폐기한다.

2. ESP(Encapsulating Security Payload)

가. ESP 프로토콜 헤더

(그림 3)은 ESP 프로토콜 헤더 구조이다. Security Payload Index 필드는 32비트로 유일한 SA를 식별하는데 사용되는 인자 중 하나이다. SA를 구분하는데 사용하는 인자는 {SPI, AH, 목적지주소}이다. Sequence Number 필드는 unsigned 32비트 값으로 SA가 설정될 때 송수신측에서 모두 0으로 셋팅된다. 그 후 전송시마다 송신측에서는 그 값을 1씩 증가시키고 수신측에서는 이 값을 검사하여 재전송 공격(Replay Attack)을 검사한다. 수신측에서 이 값을 검사함으로써 재전송 방지 서비스(Anti-Replay)가 성립된다. Payload Data는 Next Header 필드에서 지정한 상위 계층의 데이터가 기록되는 필드로 길이는 가변적이다. Padding는 바이트 정렬을 맞추기 위해 사용되는 필드로 0~255 사이의 값을 가질 수 있으며, 패딩된 크기는 Pad Length 필드에 기록된다. Next Header는 페이로드 데이터의 형태를 지정하는 8비트 필드로 IANA에서 지정한 값을 사용한다. Authentication Data 필드는 선택 사항이며 사용 인증 함수에 의해 필드 크기가 결정된다.

나.. ESP 프로토콜 처리

ESP 프로토콜은 트랜스포드(Transport Mode)와 터널 모드(Tunnel Mode) 두 가지의 운용 모드를 가지고 있다. 트랜스포드 모드는 일반적으로 보안 호스트 구현시 사용되며 상위 계층 프로토콜에 대한 보호 서비스를 제공한다. 터널 모드의 경우는 보안 호스트 및 게이트웨이 구현시 모두 적용되며 outer IP 헤더를 새로이 생성하여 inner IP 헤더를 포함한 inner IP 패킷 전체에 대한 보호 서비스를 제공한다.

패킷을 송신하는 단계인 Outbound 패킷 처리 과정 및 수신 단계인 Inbound 패킷 처리 과정은 다음 (그림 4)와 같은 순서로 이루어 진다.

패킷을 송신하는 단계인 Outbound 패킷 처리 과정에서는 먼저 SA가 설정되어 있는지 SAD를 찾는다. 만약 설정된 SA가 없으면 정책에 따라 새로운 SA를 설정하고, 이미 설정된 SA가 있으면 전송하고자 하는 패킷을 암호화한 후, 재전송 공격 방지 서비스를 위하여 SN(Sequence Number)을 생성한다. 이때 SN 값은 초기값인 0으로 설정한다. 다음으로 전송 중 변하지 않거나 수신측에서 예측 가능한 필드 값을 이용하여 ICV를 계산하고, 패딩을 추가한 후 전송할 패킷 단위로 분할한 후 패킷을 전송한다.

패킷을 수신하는 단계인 Inbound 패킷 처리 과정은 송신 단계의 역순과 유사한 처리를 한다. 먼저 수신된 패킷을 조합한 후 AH 헤더의 {SPI, AH, 목적지주소}를 이용하여 관련 SA를 찾는다. 만약 설정된 SA가 없는 경우는 해당 패킷을 폐기하게 된다. 이미 설정된 SA가 있는 경우는 Sliding Receive Window와 Bit Masking 방법을 이용하여 SN과 ICV에 대한 검증을 수행한 후 패킷의 복호화를 수행한다. ICV 검증 단계에서 수신 패킷 내의 ICV 값이 AH 내의 값과 일치하면 통과시키고, 그렇지 않으면 해당 패킷을 폐기한다.

III. IPsec 표준화 동향

1. IETF 조직 현황

IETF[8]에는 Application Area(APP), General Internet Area(GEN), Internet Area(INT), Operation & Management Area(OPS), Routing Area(RTG), Transport Area(TSV), User Service Area(USV) 및 Security Area(SEC)등의 8개 Working Area가 있다. 8개의 Working Area에는 각각 적게는 1개에서 많게는 26개까지의 Working Group(WG)이 있어 각 WG별 Charter에 의해 정해진 분야의 관련 기술에 대한 표준화 과정을 진행하고 있다.

2. IPsec 관련 Working Group

보안 관련 표준화의 진행은 SEC에 의해 주도되며, SEC에는 표 2에 나타낸 것과 같이 16개의 WG이 있다. SEC의 16개 WG중 IPsec 과 밀접한 관련이 있는 WG은 IPsec, IPsp, IPsra이다.

가. IPsec WG

IPsec WG에서는 IP의 client 프로토콜에 대한 보호를 제공하기 위한 방법을 개발하고 있으며 데이터에 대한 기밀성, 무결성, 접근 제어 및 인증 등의 보안 서비스를 복합적이고 유연하게 제공하기 위한 네트워크 계층에서의 보안 프로토콜에 대한 연구 및 표준화를 진행하고 있다. 현재까지 IPsec WG에서는 AH, ESP, IKE, 데이터 암호 알고리즘 및 데이터 인증 알고리즘 등의 기본적인 보안 프로토콜이 RFC(Request For Comments)로 완성되어 있는 상태이다. 더 다양한 트랜스폼 알고리즘에 대한 draft, 복잡한 IKE의 기능성 확장에 대한 draft, IPsec 모니터링 및 ISAKMP Heartbeat 프로토콜에 관한 draft들이 제안되어 있는 상태이다.

나. IPsp WG

IPsp WG에서는 보안 정책 서비스를 제공하기 위한 두 가지 모델로 정책 저장소와 독립적인 모델(Repository-Independent Information Model)과 정책 저장소와 관련된 모델(Re-pository-Specific Data Model) 등을 고려하고 있으며, 정책 규격 언어인 SPSL(Security Policy Specification Language)에 대한 개발과 확장, 정책 교환 및 협상을 위한 SPP OPS (Security Policy Protocol)에 대한 개발이 이루어지고 있다. 현재까지 완성된 RFC는 없고, SPSL과 IPsec 형상 정책 모델에 관한 draft만 존재한다.

다. IPsra WG

IPsra WG에서는 일명 Road-Warriors라 불리는 휴대용 이동 단말기를 사용하여 지역 ISP(Internet Service Provider)를 통한 유선 접속 및 원격지에서 유무선 LAN을 통한 접속시 보안 서비스를 제공하기 위한 절차 및 프로토콜에 대한 표준화를 진행하고 있다. 현재까지 완성된 RFC는 없고, IPsec 원격 접근 시나리오와 PIC(Pre-IKE Credential Provisioning Protocol)에 관한 draft만 존재한다.

IV. IPsec 제품 및 인증

1. IPsec 제품군

IPsec 제품군이라 함은 IPsec을 지원하는 호스트 시스템, 게이트웨이 시스템, 라우터, VPN 서버, 방화벽 장비 및 이들 장비를 제어 통제하는 소프트웨어를 포함한다. 현재 많은 수의 인터넷 장비 제조 업체에서 IPsec을 지원하는 제품들을 생산 판매하고 있다. 다음은 각 제조 업체별로 생산되는 장비들에 대한 조사 내용이다.

가. 3Com(http://www.3com.com/)

3Com에서는 IPsec을 지원하는 지능형 라우터, 터널 스위치 및 VPN 관리 소프트웨어 제품을 시장에 내놓고 있다. 대부분의 제품들은 기본적으로 VPN 기능을 제공하고, VPN 서비스 를 위한 계층 2와 3의 터널링 프로토콜을 제공한다. 또한 다수의 암복호 알고리즘 및 인증 알고리즘을 제공한다. 다음 <표 3>은 3Com IPsec 제품군의 특징을 보여준다.

나. Axent(http://www.axent.com/)

Axent에서는 VPN 서버/클라이언트, 방화벽 및 보안 소프트웨어 제품을 생산하고 있다. 다음 <표 4>는 Axent IPsec 제품군의 특징을 보여준다.

다. Check Point Software(http://www.checkpoint.com/)

Check Point Software에서는 방화벽, 실시간 침입 탐지, VPN 게이트웨이 및 VPN과 관련된 주변 소프트웨어와 가속 카드 등을 생산한다. 다음 <표 5>는 Check Point Software IPsec 제품군의 특징을 보여준다.

라. Cisco(http://www.cisco.com/)

Cisco에서는 대부분의 인터넷 관련 장비 및 제품들에 IPsec 기능을 탑재하고 있으며, IETF의 표준화에서 막강한 영향력을 행사하고 있는 업체이다. 라우터 운영 체제인 IOS를 비롯하여 방화벽, 라우터, 스위치 등을 생산하고 있다. 다음 <표 6>는 Cisco IPsec 제품군의 특징을 보여준다.

마. Lucent Technologies(http://www.lucent.com/)

Lucent에서는 Cisco와 마찬가지로 대부분의 인터넷 관련 장비 및 제품들에 IPsec 기능을 탑재하고 있다. VPN 서버/클라이언트를 비롯하여 방화벽, 침입 탐지 엔진, 보안 관리 서버 등을 생산하고 있다. 다음 <표 7>은 Lucent IPsec 제품군의 특징을 보여준다.

바. NewBridge(http://www.newbridge.com)

NewBridge에서는 IPsec 기능이 탑재된 VPN 서버/클라이언트, VPN 서비스 관리 시스템 등을 생산하고 있다. 다음 <표 8>는 NewBridge IPsec 제품군의 특징을 보여준다.

사. RadGuard(http://www.radguard.com/)

RedGuard는 이스라엘 보안 관련 제품 전문 회사로 VPN 게이트웨이, 인증 게이트웨이, 방화벽, CA 등 보안 관련 전체 제품군을 빠짐 없이 모두 생산하고 있다. 다른 인터넷 보안 장비 생산 업체보다 막강한 기술력을 바탕으로 다양한 보안 기능들을 선보이고 있다. 다음 <표 9>은 RadGuard IPsec 제품군의 특징을 보여준다.

아. RedCreek(http://www.redcreek.com/)

RedCreek은 미국의 보안 관련 제품 전문 회사로 VPN 게이트웨이, 보안 관리 소프트웨어, VPN 클라이언트용 소프트웨어 및 하드웨어 제품을 생산하고 있다. 다음 <표 10>은 RedCreek IPsec 제품군의 특징을 보여준다.

자. VPNet(http://www.vpnet.com/)

VPNet은 VPN 게이트웨이, 원격 클라이언트, 관리 장비 등 VPN 지원 보안 장비군을 생산한다. 다양한 크기의 VPN 장비를 공급하며 표준화에 충실한 제품을 생산하고 있다. 다음 <표 11>은 VPNet IPsec 제품군의 특징을 보여준다.

2. IPsec 인증

가. ICSA(http://www.icsa.net/)

ISCA에서는 항바이러스(anti-virus) 제품, 방화벽, IPSec/VPN 장비, 암호화 장비 및 모니터링 장비등 네트워크 보안과 관련된 장비에 대한 인증 서비스를 해주고 있다. 현재 Cisco를 비롯하여 IBM, Lucent Technologies, Alcatel, New Bridge, Nortel Networks등 대규모 인터넷 장비 공급 업체에서 생산된 IPsec 제품들이 ISCA의 정보보호 보증 서비스를 통해 인증을 받고 있다. 현재 Criteria 1.0과 Criteria 1.0A를 기반으로 한 IPsec 장비 인증이 활발하게 이루어지고 있다.

나. ICSA의 IPsec 제품 인증 프로그램

ICSA의 IPsec 장비 제품 인증 프로그램은 총 6가지로 나뉘고 있으며, 각 버전에 대한 설명은 <표 12>과 같다. 각 버전에 표시되어 있는 기능에 대한 시험을 진행하며, 각 버전의 요구 기능을 만족할 경우 다음 (그림 5)와 같은 인증 로고를 부여한다.

V. 결 론

IPsec 기술은 현재까지 표준화 과정을 거친 프로토콜 중 가장 성공한 프로토콜로 손꼽히고 있다. IPsec은 IP 계층에서 직접 보안 서비스를 제공함에 따라 상위 계층 프로그램의 변경이 필요하지 않으며, 또한 추가적인 비용을 부담하지 않고 현재의 응용 서비스를 그대로 유지하면서 송수신되는 정보의 보안을 보장할 수 있게 되었다. 물론 현재의 인터넷 장비들이 IPsec을 지원하는 장비로 대체되면서 인터넷이 진화하기에는 많은 시간이 소요될 것으로 보이지만, 최근 급증하는 정보화의 역기능(해킹, 바이러스, 개인 정보 유출 등) 때문에 단시간에 인터넷 장비들이 대체되면서 IPsec 관련 장비의 시장이 형성될 가능성도 배제할 수 없는 실정이다.

현재 IPsec 기술은 VPN의 기반 기술로 사용되는 것이 일반적인 추세이며 Mobile IP 분야에서도 IPsec 프로토콜을 적용하고 있다. 앞으로 IPsec과 더불어 IKE가 함께 구현되고 소프트웨어 및 하드웨어의 통합으로 인터넷 보안 서비스가 제공될 것으로 보인다. 그리고 IPv6로 인터넷 프로토콜이 전환되면 본격적으로 IPsec 프로토콜이 인터넷 보안 프로토콜로서 널리 이용될 것으로 보인다.

<참 고 문 헌>

  1. J. Ioannidis and M. Blaze, The Architecture and Implementation of Network-Layer Security Under Unix, Forth USENIX Security Symposium Proceedings, October 1993.
  2. RFC2401: Security Architecture for the Internet Protocol, S. Kent and R. Atkinson, November 1998.
  3. RFC2402: IP Authentication Header, S. Kent and R. Atkinson, November 1998.
  4. RFC2403: The Used of HMAC-MD5 within ESP and AH, C. Madson and R. Glenn, November 1998.
  5. RFC2404: The Used of HMAC-SHA-1 within ESP and AH, C. Madson and R. Glenn, November 1998.
  6. RFC2405: The ESP DES-CBC Cipher Algorithm with Explicit IV, C. Madson and N. Dorawamy, November 1998.
  7. RFC2406: IP Encapsulating Security Payload, S. Kent and R. Atkinson, November 1998.
  8. http://www.ietf.org/

+ Recent posts