최근 스마트폰을 통한 mVoIP 즉, 스카이프와 같은 모바일 인터넷 전화 사용 제한과 관련한
기사가 많이 띄인다. 통신사에서 4만5000 원 이하 요금제 사용자들은 VoIP 이용을 차단/제한 한다는 것이다.
이에 대해 소비자들의 불만도 많은게 사실이다. 하지만, 차단을 시행한다고 했지만
실질적으로는 아직 이용이 가능하다고 한다. 단지 기사를 통해서만, 사용자들이 일단 사용을 포기하도록
유도한 것인가? 다음 기사에서 한 통신사 관계자가 한 말을 보자
통신사 관계자는 “최근 사용자들의 데이터 유형을 구분할 수 있는 딥패킹인스펙션(DPI) 장비를 도입해 트래픽 분류가 가능해졌기 때문에 곧 제한이 가능해 질 것”이라고 설명했다.
차단 정책과 관련해서는 여기서 논의할 부분이 아니니 생략하고, 패킷과 관련된 기술적 방법에 대해서
간단히 한번 생각해 보자. 스카이프,바이버,Fring 등 여러가지 VoIP 관련 프로그램들이 있는데,
이걸 요금제 별로 차단한다고 하면 우선 45,000 이하 사용자들을 구분할 수 있어야 하고 각 프로그램이
사용하는 패킷을 분석할 수 있어야 한다.
머 사용자 구분이야, 이미 데이터를 얼마나 사용하고 있는지 정보도 다 나오고 하니 이건 문제가 아니다.
프로그램을 차단할 수 있어야 하는데, 이것또한 사용되는 프로토콜을 분석하고 차단 가능성을 찾아보면 된다.
제일 간단하게는
- 특정 포트번호의 차단
- 프로토콜의 특정 패턴 차단
이 되겠다. 그런데 포트번호로 다 차단하기에는 문제가 발생할 소지가 있다. 그러므로 특정 패턴 차단 방식이 이뤄질텐데, 항상 구분할 수 있는 특정 패턴이라면 간단하지만, 다이나믹한 형태로 프로토콜이 변하면 쉽지 않다. 하지만, 기본적으로 정의된 형태가 있기 때문에 차단이 가능해 질 것이다.
"기술적으로만 본다면야 차단하는건 충분히 가능하다." 문제는 실제 필드에 이것을 쉽게 반영할 수 있느냐 하는 것이다. 스마트폰 사용인구가 증가하면서 이로인한 데이터가 폭발적으로 증가하고 있다.
엄청난 트래픽 양을 건뎌야 하고, 정확히 판단 분석해야 하며, 45,000 요금제 이하 사용자를 대상으로 적용해야 한다는 것이다. 통신사에서는 기사를 통해 차단한다고 밝혔지만, 실질적으로는 적용을 못하고 있다.
아마, 이런 여러 이슈들 때문에 쉽지 만은 않을 것이다. 각 트래픽에서 구분해 내는 어떤 시그너처 패턴을 작성한다고 했을때, 트래픽 양등도 고려하여 시그너처 패턴이 작성되어야 한다. 다음은 대표적인 오픈소스 침입탐지 시스템인 스노트에서 사용가능한 시그너처 패턴 예이다.
Signature 1 - Skype VoIP Initialization
tcp $HOME_NET any -> any any (msg:"P2P CHAT Skype VoIP Initialization";flow:to_server,established; content:"|8046010301002d0000001000000500000400000a 0000090000640000620000080000030000060100800700c003 0080060040020080040080|";depth:112;classtype:polic y-violation;sid:1000013; rev:1;)
Signature 2 - Skype client login -- reply from server
tcp $EXTERNAL_NET 1024: -> $HOME_NET 1024: (msg:"Skype client login -- reply from server"; flags:AP,SUFR12; flow:to_client,established; flowbits:isset,skype_client_login; dsize:5; content:"|17 03 01|"; depth:3; sid:1000012; rev:2; )
Signature 3 - P2P Skype client setup get newest version attempt
tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"P2P Skype client setup get newest version attempt"; flow:to_server,established; uricontent:"/ui/"; uricontent:"/getnewestversion"; content:"Host|3A| ui.skype.com"; classtype:policy-violation; sid:5694; rev:4;)
등등...
탐지만 하는 것이야 문제가 발생할 것도 없고 큰 이슈가 없다. 하지만, 차단 으로 들어가면 여러가지 고려해야 될 것이 많아지게 된다. 또한, 패턴 형태에 따라 다르겠지만 우회할 수 있는 가능성도 존재할 것이다. 우회 되는 형태가 발견되면 그걸 또 차단해야 할 것이고, 유지보수 비용도 크게 증가될 것이다.
또 한가지는 실시간성이다. 과금이야 실시간 적으로 데이터를 바로 볼 필요가 없기 때문에 단순히 트래픽을Tapping 형태로만 해서 데이터를 분석해 반영하면 될 것이다. 그런데, 이건 지금 사용자가 사용하려고 할때
차단해야 한다. 실시간적으로 차단이 가능해 져야 한다는 것인데, 트래픽 중간 사이에 장비가 들어가 실시간
적으로 차단하는데 문제가 발생할 소지는 없을까? 장비의 다운, 잘못된 정책, 구성 등 여러 장애원인이
존재하게 될 수 있다.
트래픽을 직접 컨트롤 하는 것과 중간에서 트래픽을 덤프하여 분석하는 것은 분명히 차이가 있다.
그러므로 충분한 테스트와 안전성이 보장되었을때 단계별로 반영이 될 것이다. 만약 차단을 한다면 말이다.
엔지니어 입장에서는 기술적으로 가능이야 하다지만, 이걸 실제 필드에 반영해 운영한다는 것은 어려움들이
존재할 수 있다. 아마 이 글을 읽는 분이 엔지니어라면 동감할 것이다.
그래도 통신사 입장에서는 먼가 차단하려고 계속 고민은 하고 있을 것이다. 이 정도로 하고 있지 않을까?
- 중간에 Tapping 하여 트래픽 데이터 유형 분석
- 가장 많이 이용되는 mVoIP 앱 선정, 사용되는 프로토콜 형태 패턴 분석
- 패턴을 탐지용 형태로만 반영하여 관찰 (False Positive 등)
- 충분히 검증되었다 판단되면, 시범적으로 트래픽이 적은 구간에 시범 적용 / 테스트
mVoIP 차단을 떠나서 통신사에서는 트래픽을 제어할 수 있는 기술은 분명 필요하다. 그 영역에 따라 달라지겠지만 말이다. 어찌되었든 '패킷' 바로 이것 참 재미있는 놈이다. 이놈을 잘 알게 되면 흐름을 다 알 수 있으니 말이다.
마지막으로 앞으로 VoIP 는 꾸준이 크게 증가될 것이 뻔하다. 통신사에서는 이익저해 요소로 이것을 단지 차단하려고만 할게 아니라, 현재의 글로벌 트랜드를 보았을때 새롭게 대처해 나갈 수 있는 방안이 필요하다. 지금 시점에서는 차단이 이득일지 모르나, 앞으로는 아니다. 그리고 소비자들이 분명 사용가능한 데이터 용량 내에서 이용하겠다는데 말이다.
최근 발표된 넥서스 S 에는 VoIP 를 이용할 수 있는 기능이 들어가 있다고 한다. VoIP 를 지원하는 앱을 따로 설치할 필요도 없이 전화번호부에서 바로 이용 가능하다는 것이다. 점차, 인터넷전화의 대세가 예견된다.
어찌되었든 나는 소비자의 편에서 ^^
Internet calling (VoIP/ SIP support)
Gingerbread allows Nexus S to place Internet calls with a SIP account. This allows for enhanced VoIP dialing to other SIP accounts and even phone numbers.
