[VoiceOps] Voice Security in MPLS networks -- When is it necessary?

[Mark R Lindsey]

The final recommendation must be based on calculus of risks and costs,  
which is dependent on a given network. Begin by considering these:

1. IP network transport equipment is often in the same physical  
location with legacy telecom equipment. There's no substantial,  
generalizable difference the physical security of the two systems.

2. As Lee Riemer mentioned, "Private" MPLS networks are often built on  
ordinary "public" links, using the very same equipment.

3. Encryption for RTP is trendy among the IETF draft-writers, and  
others who don't have to build, operate, and troubleshoot the networks.

4. Encrypted RTP (sRTP) adds some costs: (a) It limits the choice of  
devices, excluding some lower-cost options; (b) Key distribution must  
be handled; (c) RTP can be analyzed only after it is decrypted, so the  
cost of troubleshooting is  greater; (d) the PSTN cannot be used as a  
transport for the RTP; (e) There is a modest increase in overhead;

5. sRTP is supported by exceptionally few media servers, conferencing  
servers, voicemail systems. If the intention is to support end-to-end  
encrypted RTP for every conversation, then the implementation options  
are limited. Many SP implementations of sRTP are encrypted only from  
the CPE to the SBC, or between similar CPE.

6. ISDN is exceptionally easy to wiretap, although most CCNA's don't  
have the equipment sitting around. US  $2k will buy a SunSet tester  
with PRI module that lets you see all calls and listen to them.

7. Key distribution is nontrivial, but you have to get it right for  
the encryption to work. How will you ensure  that only the right  
people have access to the sRTP keys in use?

8. When contemplating any security measure, you must determine who the  
enemy is against whom you are defending; e.g.,
	---- Are you concerned that the service provider will wiretap?
	---- Or other employees or contractors?
	---- Strangers with physical access to your building?
	---- Corporate spies?
	---- The Government?
	---- Other Governments?
Each of these attackers has certain resources. The Government, for  
example, has the FBI and the NSA. Corporate spies may have large  
funding -- enough to attack captured sRTP.

9. When contemplating any encryption technique, you must determine the  
intended lifetime of protection. All encryption mechanisms can  
eventually be broken, given enough time. How long do you need the  
conversation to remain a secret? With sRTP done badly, you may have  
the appearance of encryption, but remain vulnerable to decryption  
within minutes.

10. IANAL. In the US, it's a Federal Crime to do what you're trying to  
defend against. From http://openjurist.org/713/f2d/389/united-states-v-ross 
  -- Under federal wiretapping law it is a felony for any person to  
willfully intercept or willfully disclose the contents of a wire  
communication. 8 U.S.C. § 2511(1)(a) & (c) It is, however, not  
unlawful for an officer or employee of a communication common carrier  
to intercept or disclose the contents of a wire communication while  
engaged in an activity which is necessary to the rendition of his  
services. 18 U.S.C. § 2511(2)(a)(i).

18 U.S.C. § 2511(1)(a) & (c) provide in pertinent part:
(1) Except as otherwise specifically provided in this chapter any  
person who--
(a) willfully intercepts ... any wire communication; [or] ...
(c) willfully discloses ... to any other person the contents of any  
wire--... communication, knowing or having reason to know that the  
information was obtained through the interception of a wire ...  
communication in violation of this subsection ... shall be fined not  
more than $10,000 or imprisoned not more than five years, or both."
18 U.S.C. § 2511(2)(a)(i) provides:
(2)(a)(i) It shall not be unlawful ... for an operator of a  
switchboard, or an officer, employee or agent of any communication  
common carrier, whose facilities are used in the transmission of a  
wire communication, to intercept, disclose or use that communication  
in the normal course of his employment while engaged in any activity  
which is a necessary incident to the rendition of his service ...  
Provided, That said communication common carriers shall not utilize  
service observing or random monitoring except for mechanical or  
service quality control checks.


mark r lindsey at e-c-group.com http://e-c-group.com/~lindsey +12293160013


On Oct 14, 2009, at 12:32 PM, <Guy.Ram at t-systems.com> wrote:

> Hello,
>
> Like your kind response to this question:
>
> Would folks agree that for SIP traffic in a private MPLS network  
> should not necessarily require encryption. What is your advise for  
> the normal Enterprise ? I’m trying to understand where it makes  
> prudent sense to enable encryption and where it’s redundant.
>
> I’m trying to counter this statement:
>
> that encryption of the media stream should be encouraged. Although  
> the MPLS network is private, it is easy to setup a traffic sniffer  
> on computers and to tap and record calls. This is unlike the ISDN  
> world where telecoms equipment is usually locked up and inaccessible  
> to most employees. Companies do accept encryption as normal overhead”
>
> What I’ve been told that most enterprise networks are switched, so  
> the connection from the desk goes to a switch and then right to the  
> VoIP system, so it’s basically non-trivial to tap a phone line that  
> way. VoWiFi is different, but there are more issues than security  
> with that. Legacy environment equivalent for wired VoIP.
>
> Also that Encryption will increase delay, reduce quality, and  
> increase BW consumption. I don’t see a lot of need for encryption  
> except across a peering point for example.
>
> Thanks,
> -guy
> _______________________________________________
> VoiceOps mailing list
> VoiceOps at voiceops.org
> https://puck.nether.net/mailman/listinfo/voiceops






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://puck.nether.net/pipermail/voiceops/attachments/20091014/ff880dc8/attachment-0001.html>