[VOIPSEC] RE: Preventing rogue RTP streams

[Geoff Devine]

There's still an issue if you are encrypting SIP and the firewall doesn't have the keying material.  An RX RTP stream will be allowed through the NAT pinhole in the NAT/FIrewall forever and it's difficult to traffic shape it since you don't know the codec model signaled in the SIP SDP.  Once you start using encryption, your SBC or firewall has to participate in the security scheme (decrypt signaling) or you have this problem.  
 
Geoff

________________________________

From: Christopher A. Martin [mailto:chris at infravast.com]
Sent: Thu 5/19/2005 8:22 PM
To: Geoff Devine; Voipsec at voipsa.org
Subject: RE: [VOIPSEC] RE: Preventing rogue RTP streams



As long as the SIP firewall Proxy (SFP) or SIP firewall ALG (SFA) are
providing a strong policy that has both the source and destination this
is lower risk, except in the case of spoofing, which would be a useful
attack against voice mail systems. In any event though, as long as the
firewall is dynamically allocating the ports and src/dst policies this
is also a short window of opportunity for such an attack, requiring
knowledge of an open attack vector.

-----Original Message-----
From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
Behalf Of Geoff Devine
Sent: Thursday, May 19, 2005 6:37 AM
To: Voipsec at voipsa.org
Subject: [VOIPSEC] RE: Preventing rogue RTP streams

If you don't have a network device between the two endpoints to perform
admission control, there is no way to prevent this condition.  In
theory, a SIP-aware NAT/Firewall device could shut the pin hole for the
RTP stream when they see a SIP BYE.  In this case, the admission control
is done by your home or corporate NAT/Firewall instead of an SBC.  Of
course, this only works if you are signaling in the clear.  As soon as
you turn on SIP encryption, you're out of luck. 

Geoff

________________________________


From: "Nhut Nguyen" <nnguyen at sta.samsung.com>
Subject: [VOIPSEC] Preventing rogue RTP streams
Hello everyone!

Since in SIP RTP packets are sent end-to-end how one can prevent SIP
endpoints to send RTP packets after a session was closed? I know that
SBCs handle this issue but am wondering if there are any other
solutions. Any pointers?

Thanks!