클라우드로 크고 싶은 블로그 입니다

SIP(Session Initiation Protocol)아래 Body 라고 불리는 SDP를 보신적 있으신가요?

 

일반적으로 SIP는 세션 제어(호개시, 호종료, 호제어 - 쉽게 말해 전화 걸고/끊고/통화중)를 하고,

바디에는 세션이 연결 되면 실제 주고 받을 내용을 적습니다.

표준에는 이미지도, 동영상도, 팩스도, 문서도 온같 잡 것 다 보낼 수 있지만, 실상 SDP(Session Description Protocol)는 거의 RTP를 주고받기 위한 용도로 많이 쓰입니다.

 

SDP 예제는 아래와 같습니다.

v=0
o=- 123456 654321 IN IP4 1.1.1.1
s=VoIP Call
c=IN IP4 1.1.1.1
t=0 0
m=audio 4000 RTP/AVP 0 8 96
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:96 opus/48000

 

주요 필드에 대한 설명은

 

o= (Origin): 세션 생성자 정보

c= (Connection): RTP를 받을 IP 주소

m= (Media): 미디어 타입, 포트 번호, 코덱 여기선 audio 4000이므로, RTP 수신 포트는 4000

a=rtpmap: 사용 가능한 오디오 코덱들

 

와 같습니다.

 

자 문제는여기서 시작 됩니다. 메세지에 IP와 포트정보가 기술되어 있으나,

현대의 대부분 인터넷은 NAT 환경입니다.

즉, 서버에서 보이는 단말의 IP와 포트가(공인IP, NAT 후) 단말이 알고 있는 IP와 포트(사설IP, NAT 전)와 다르다는 겁니다.

 

위 SDP 예제에서, 메세지만 보면, 서버 → 전화기의 RTP 흐름은

전화기는 "응, 나 포트 4000번에서 기다릴께"

서버는 "응, 나 1.1.1.1 IP에 포트 4000번으로 보낼께"

 

지만, 실제 전화기의 1.1.1.1 IP와 4000번 포트는 NAT 내부의 IP와 포트 정보입니다. 위와 같이 그냥 보내면

축하합니다. 원웨이 입니다.

 

이를 해결하기 위해,

1. STUN (Session Traversal Utilities for NAT)

2. TURN (Traversal Using Relays around NAT)

3. ICE (Interactive Connectivity Establishment)

 

등의 기술이 있지만, 자세한 건 검색이나 생성형 AI를 활용하고,

여기선 실제 통신사에서 쓰이는 SBC 동작을 알아보겠습니다.

 

단말기 IP	NAT라우터 IP	SBC IP
1.1.1.1	2.2.2.2	3.3.3.3

이라고 가정 하면, 전화기에서 아래와 같이 INVITE SDP 에 보냅니다.

c=IN IP4 1.1.1.1
m=audio 4000 RTP/AVP 0 8

 

그러나, SBC에서는 웬 메세지에는 없는 듣도보도 못한 IP인 2.2.2.2 에서 메세지를 받게 됩니다.

 

그리고 SBC는 아래와 같이 200OK SDP를 응답합니다.

c=IN IP4 3.3.3.3
m=audio 6000 RTP/AVP 0 8

 

일단, SBC 는 단말기가 NAT 내부에 있다는 걸, SDP와 메세지를 수신한 IP가 다르다는 사실로 알게 됩니다.

(사실 대부분의 SBC는 REGISTER 메세지의 Contact 헤더를 통해 등록 단계에서, 해당 전화기의 RTP NAT 처리 여부를 결정합니다.)

 

이제 SBC는 3.3.3.3:6000로 패킷이 들어오기를 기다립니다.

단말기는 SDP가 포함된 200OK 메세지를 받자마자, 1.1.1.1:4000 → 3.3.3.3:6000으로 보냅니다.

그러나, NAT 라우터가 포함 된 경로에서는 1.1.1.1:4000 → 2.2.2.2:5000 → 3.3.3.3:6000으로 보냅니다.

 

SBC는 3.3.3.3:6000 으로 실제로 들어오는 IP와 포트가 2.2.2.2:5000 라는 걸 확인하고,

3.3.3.3:6000 → 2.2.2.2:5000 → 1.1.1.1:4000 로 보내게 됩니다.

 

드디어 양방향 정상적으로 음성이 들리게 됩니다!!!

 

그런데 말입니다.

 

악의 적인 누군가(feat. 나쁜 놈)가 SBC가 대기 중인 3.3.3.3:6000 으로 RTP를 보내서, 어쩌다 보니, 단말이 보낸 것보다 먼저 도착하게 되면, 호가 나쁜 놈과 연결되는 문제점이 있습니다. (RTP Inject)

 

이를 방어하기 위해, 대부분의 NAT 라우터의 NAT Pool은 네트워크로 지정된다는 점을 활용합니다.

같은 NAT 라우터를 거치는 경우 SIP 메세지는 2.2.2.2 에서 받았는데 RTP는 4.4.4.4 에서 오는 경우는 거의 없다는 점을 활용해, 2.2.2.2 외의 IP(또는 네트워크)에서 오는 RTP는 무시합니다.

(물론, 2.2.2.2에서도 RTP Inject 공격하는 놈이 있을 수 있지만 그러면, 범인은 이안에 있다!!!)

 

그리고 요즘 SRTP를 지원하는 단말이 많아지고 저렴해지면서, SRTP를 단말과 SBC에서 적용해 SDP의 키값을 모르면 통화가 불가능하게 만들기도 합니다.

 

마지막으로 좋은 SBC는 자체의 보안기능도 훌륭합니다.

RTP 공격을 받은 포트는 오픈하지 않거나, 특정 IP에서 허용되지 않은 포트로 RTP를 전송하면 해당 IP를 차단하는 등의 기능도 가지고 있습니다.

 

SBC는 가성비 좋은 친구 입니다.