[VOIPSEC] Why a secure keyechange for media encryption?

Hadriel Kaplan HKaplan at acmepacket.com
Fri Apr 28 12:41:56 PDT 2006


Inline.

 

  _____  

From: Weidong Shao [mailto:weidongshao at gmail.com] 
Sent: Friday, April 28, 2006 3:16 PM
To: Hadriel Kaplan
Cc: voipsec at voipsa.org
Subject: Re: [VOIPSEC] Why a secure keyechange for media encryption?

 

if signaling is encrypted, how does the firewall open up ports to let  RTP
media pass through?
unless you want to leave firewall wide open for RTP data (quite a large port
range)

 

Some firewalls (and almost all home NATs) have rules that allow UDP
initiated from inside out to create a "hole", and let the reverse flow UDP
with the same IP-layer addressing come back in.  There are variations of how
much of the reverse flow's addressing/port info must match the outbound one
to be let back in, which the STUN RFC defines NAT behaviors for as well
(e.g., full conical, port restricted, symmetric).  Some firewalls block any
UDP they don't "know" about through some protocol, and for them you would
either use a protocol to do so, or the enterprise would use an
enterprise-SBC to do so, or they would put rules in their firewall allowing
ranges of UDP but only from specific external addresses (for example, only
from their service provider's SBCs).

 

Ultimately there are some firewalls that don't want to let any UDP through
period, and the only way around those is to tunnel it in a something else as
a transport (ie, SSL-vpn, IPsec tunnel mode, HTTP, etc.).  

 


sure, if stun/ICE is used, there is no need for NAT rewrite of SDP. 
An SBC will complicate hop-by-hop signaling encryption. 

 

No it doesn't.  An SBC is the first SIP/TLS hop.  It is no more complicated
for SIP/TLS than connecting to a proxy for SIP/TLS.  If the SBC isn't
configured to do TLS, then it won't, just as a proxy won't.

 

-hadriel

 




More information about the Voipsec mailing list