[VOIPSEC] RE: Preventing rogue RTP streams

[Christopher A. Martin]

Yep, same goes for firewalls.  And even TLS is at risk, since if a user uses
wifi the SSL can be attakced and information gleaned. It is merely a matter
of a third party sniffing wifi (encrypted or not) and then determining what
type of login to replay and hijack that method before sending the info onto
the real server.

-----Original Message-----
From: Geoff Devine [mailto:gdevine at cedarpointcom.com] 
Sent: Friday, May 20, 2005 6:41 AM
To: Chris at infravast.com; Voipsec at voipsa.org
Subject: RE: [VOIPSEC] RE: Preventing rogue RTP streams


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!