[음성패킷망][VoIP]음성패킷망(VoIP)의 발전사, 음성패킷망(VoIP)의 정의, 음성패킷망(VoIP)의 장단점, 음성패킷망(VoIP)의 네트워크 구성, 음성패킷망(VoIP)과 보안, 음성패킷망(VoIP)과 Firewall/NAT 분석

소개글

[음성패킷망][VoIP]음성패킷망(VoIP)의 발전사, 음성패킷망(VoIP)의 정의, 음성패킷망(VoIP)의 장단점, 음성패킷망(VoIP)의 네트워크 구성, 음성패킷망(VoIP)과 보안, 음성패킷망(VoIP)과 Firewall/NAT 분석에 대한 보고서 자료입니다.

목차

Ⅰ. 음성패킷망(VoIP)의 발전사
1. PC 대 PC
2. PC 대 전화
3. 전화 대 전화
4. Web to Phone

Ⅱ. 음성패킷망(VoIP)의 정의

Ⅲ. 음성패킷망(VoIP)의 장단점
1. 장점
1) 이용자 측면의 장점
2) 유지/보수 측면의 장점
2. 단점
1) 기존 전화기에 비해 상대적인 음질 저하
2) 프로토콜 호환성 문제
3) 사용상의 편의성 문제

Ⅳ. 음성패킷망(VoIP)의 네트워크 구성
1. Gateway
2. Terminal
3. Gatekeeper
4. MCU
5. Gateway 구성
6. VoIP Gateway & Gatekeeper

Ⅴ. 음성패킷망(VoIP)과 보안

Ⅵ. 음성패킷망(VoIP)과 Firewall/NAT

참고문헌

본문내용

TTP와 매우 유사한 프로토콜로 보안 역시 HTTP의 보안 메커니즘을 주로 사용한다. 기본적으로 패스워드 기반의 Basic Authentication과 Digest Authentication을 지원하며, End-to-end 보안을 위해 PGP 기반의 강한 인증 및 암호화 기능을 사용하도록 권고하고 있다. SAP의 경우는 Multicast의 특성상 응용계층의 보안 프로토콜인 PGP나 S/MIME을 권장하고 있다. RTP/RTCP는 H.323이나 SIP, RTSP 등 대부분의 VoIP 시스템에서 미디어 스트림의 전송을 위해 공통적으로 사용하는 프로토콜이다. IETF의 RTP/RTCP 표준문서에서는 기본적으로 보안을 위해 IPSEC과 같은 하위계층의 보안 인프라를 사용하는 것을 전제로 하고 이러한 보안 인프라가 일반화되기 전에 사용될 목적으로 자체 프로토콜에서 PEM 방식의 변형으로 DES CBC로 암호화하는 방법을 제시하고 있다. 그러나 현재의 IPSEC은 키 관리나 multicast 지원문제, CBC 모드 암호화의 에러 확산문제나 Random access property 등 다양한 환경에서 적용되기에는 무리가 있으므로 최근 IETF의 AVT WG에서는 미디어 스트림의 보안을 위한 다양한 요구조건을 바탕으로 secure RTP라는 RTP/RTCP의 보안 프로파일을 표준화 중에 있다.
Ⅵ. 음성패킷망(VoIP)과 Firewall/NAT
VoIP 프로토콜의 특성상 기존의 Firewall이나 NAT를 통과하는 것은 VoIP 시스템 자체나 Firewall/NAT에서의 변경없이는 거의 불가능하다. 그러나 이 문제는 VoIP 시스템의 실제 사용을 위해서는 반드시 해결되어야 할 중요한 과제이므로 IETF에서는 다양한 제안들이 논의되고 있다. Firewall/NAT 문제를 해결하고자 하는 접근방법은 크게 다음의 세 가지로 나눌 수 있다. 가장 쉽게 생각할 수 있는 것이 Firewall이나 NAT에서 Application-level proxy나 Gateway를 지원하는 것이다. 그러나 VoIP 프로토콜 자체의 복잡성과 다양한 응용 시나리오로 인해 Transparent한 Proxy/Gateway를 지원하는 것은 결코 쉬운 일이 아니며, Firewall/NAT에서의 지나친 과부하로 인해 병목현상을 유발할 수 있다. 또한 다양한 VoIP 프로토콜별로 Proxy나 Gateway를 지원하는 것은 이들 프로토콜의 발전에 따라 끊임없이 upgrade시켜 주어야 하므로 개발이나 관리 측면에서도 scalable한 접근방법은 되지 못한다. 그러나 Proxy나 Gateway가 과도기적으로 가장 빨리 Firewall/NAT 문제를 해결할 수 있는 방법이기도 하므로 현재의 주요 Firewall 업체들은 이 방법을 주로 사용하고 있다. 그러나 이들 상용 제품이 지원하는 프로토콜은 아주 단순한 시나리오일 뿐이고 문제를 완전히 해결해 주지는 못한다.
다음으로 생각할 수 있는 것은 Firewall traversal 방법이다. 이는 Firewall이나 NAT 자체보다 VoIP 단말과 VoIP proxy쪽에서의 변경을 통해 Firewall을 안전하게 통과하고자 하는 것이다. SOCKS V5를 이용하거나 이와 유사한 Firewall traversal protocol을 이용할 수 있다. SOCKS V5는 Generic session-level proxy로 거의 대부분의 응용 프로토콜을 중계해 줄 수 있으나, UDP 통신의 제어를 위해 별도의 TCP control channel을 이용하므로 UDP를 주로 사용하는 멀티미디어 통신의 경우 scalability면에서 문제가 될 수 있다.
마지막으로 IETF의 MIDCOM WG에서 주력으로 개발 중인 것이External firewall control protocol이다. 이 역시 첫 번째 방법과 유사하게 Firewall이나 NAT에서의 변경을 전제로 한다. 그러나 첫 번째 방법의 문제점을 해결하기 위해 Application proxy/Gateway를 Firewall/NAT로부터 분리시켜 이들이 필요시 마다 Firewall Control Protocol을 이용해 Firewall/NAT를 조절하여 필요한 포트를 열고 닫거나 Address binding을 생성, 소멸시켜 주고자 하는 것이다. 이는 기존의 각종 VoIP Proxy들을 그대로 이용하여 Firewall/NAT를 외부에서 조절할 수 있으므로 장기적으로 가장 바람직한 접근방법이라 할 수 있다. 그러나 이를 위해서는 Firewall/NAT, Proxy들을 upgrade시켜야 하고 구체적인 Firewall Control Protocol(FCP)이 아직 표준화되지 않은 만큼 실제로 적용 가능하기까지는 상당한 시일이 흘러야 할 것으로 보인다. FCP의 대안으로 기존의 SOCKS V5나 RSVP를 확장시켜 사용하는 방법을 고려할 수 있다.
위와 같은 Firewall/NAT 통과 방법들은 그 자체로서는 하나의 솔루션이 될 수 있으나 문제는 패켓이 인증이나 암호화를 통해 그 본체가 보호되는 경우 제 기능을 할 수 없다는 것이다. 예를 들어 SIP에서는 일부 헤더 필드들과 메시지 body 부분을 PGP로 End-to-end로 보호하는 방법을 권장하고 있으나 메시지 body 부분에 미디어 채널을 열기 위한 SDP가 들어 있는 경우 Firewall이나 NAT에서 그 어드레스/포트 정보를 알 수 없으므로 제 기능을 할 수 없다. 그러나 만일 기업망의 내부 네트웍이 안전하다는 가정하에 End-to-end의 한 종단이 네트웍 경계의 Firewall이나 Proxy가 된다면 무리없이 동작 가능할 것이다.
참고문헌
◈ 권순일, 국내 VoIP 서비스 현황 및 향후 전망, 세종대 정보통신대학원, 2005
◈ 김경모, 무선VoIP, 그리 먼곳에 있지 않다, 미래에셋증권
◈ 배한수, KT VoIP 사업동향, 전자신문-Digital Times, ○○군 VoIP 도입결과보고, KT 멀티미디어연구소
◈ 정진욱 외, 컴퓨터 네트워크(VoIP, QoS), 생능출판사, 2003
◈ KIS 7 (93), 전산망 보안관리를 위한 보고서, 전산센터의 물리적 보안, 1993

키워드

음성패킷망,   VoIP,   전화,   음성전화,   통신