[VOIPSEC] Policy modifications for VOIP

Tue Mar 22 12:40:09 CST 2005

Good summary Anne. Just wanted to expound on a couple of issues
although your email is definitely a broader brush.

1) On the issue of Redundancy and failovers from a VoIP point of view

As soon as you have made a conscious decision as an organization to
converge Voice and Data on your network (you can extend this to Video
as well, though I do not have much experience with that) you MUST and
i repeat MUST make Redundancy a high priority goal of your network
edge devices. The EDGE devices that I am thinking of here are your
switches, proxy servers, gateways, and border controllers. The edge of
your network is what lets traffic (an in particular voice traffic) in
and out of your network. If these fail with no failover redundancy
present, you can easily shut down all voice on your network. One
redundancy option may be to have a purely PSTN bypass to all VoIP
which is accessed using a special DID/DNIS to get to the outside world
in case all your VoIP fails. While I think this is a good option
regardless, it serves only like a "lantern" in case of a total
"blackout". The goal of implementing redundancy and failover for VoIP
should be to ensure reliability and (more importantly) availability of
your network edge devices. For this, a couple strategies come to mind.
Here I list these options with SIP on my mind.

a)  A pair of redundant proxies
Deploy at least a pair of redundant proxy servers behind a Session
Border Controller. Between the pair of proxy servers, deploy one as a
primary and the other as secondary and make sure the primary updates
call state information to the secondary. At startup, the primary is
active and secondary is inactive (standby). In case of network
failure, software fault or system crash, the standby takes over based
on the last known call states. Calls in conversation thus stay up even
in case of primary failure. To switch back to primary, an
administrator troubleshoots and locates the problem, restarts the
primary - the primary then requests the active secondary to sync back
its call state information and go back into standby mode.

b) Alternate network routes to peer network's edge
Better still, if you can afford it deploy at least on more Session
Border Controller going to the same peer proxy but on a different
network route. Deploy a pair of proxies behind each Session Border
controller.

2) On the question of "Is security built into your network
infrastructure?" - again from a VoIP point of view:

It is common practice now to use Firewalls and Network Address
Translators to protect/shield your data networks. So the real question
should be rephrased as - are you making your VoIP secure on top of an
already secure data network. One of the challenges of VoIP (at least
H.323 and SIP/SDP) is that the protocol requires the negotiation of
ports, opening and closing of multiple ports on a per call basis. Thus
the fundamental paradigm has shifted from "app-centric" network access
to a "call-centric" network access. This puts unusual demands on
traditional firewalls and NATs. There is no simple way to just open up
a range of ports for a VoIP protocol and declare that your network is
now secure. Therefore, the case for Session Border Controllers on the
market. A Session Border Controller essentially parses the protocol
messages for ports being negotiated, opens and closes the ports as the
state of the call changes. The logical place for an SBC in your
network would be directly behind you traditional firewall and in front
of your proxy server. An additional way to ensure protection from
snooping of protocol messages (specially in case SIP since it is ASCII
text) is to encrypt at the transport layer - implying use of TLS over
TCP as a transport protocol for SIP.

I think these two are high priority issues in converged network design.

At UCN we are working towards exactly these goals - our highest
priority being the redundant proxy servers and other redundant edge
devices.

Pankaj Shroff
Sr Telecom Engineer
UCN Inc
pankaj.shroff at ucn.net
shroffg at gmail.com

On Mon, 21 Mar 2005 13:44:04 -0500, Coulombe, Anne L
<Anne.Coulombe at enterasys.com> wrote:
> Mark & All,
> 
> I think you just opened a larger subject when VoIP is part of true
> convergence infrastructure, as policy is not only dealing with the
> business continuity and security mods anymore. It is also as case of:
> 
> *         Physical and networking access
> 
> *         Redundancies, fail overs, fail safe, back-up power
> 
> *         Authentication onto the network
> 
> *         Authorization to access network resources and services
> 
> *         Network policies (at port, user, app level) during 'normal'
> operations
> 
> *         Network policies, QoS, CoS and other setting during a threat
> event  ... is VoIP the most important application?  Should VoIP keep
> running no matter what, should it run for say 1 hour, then another
> convergence app such as the HVAC system takes precedence?
> 
> *         Which leads to detection of a threat event whether external or
> internal, and the reaction from the network as well as the VoIP
> application/environment ... update policies on the fly e.g. protocol
> lock-out, user quarantine, redirection, location detection, permitted
> users, permitted application, bandwidth prioritization, etc
> 
> *         Who controls all this?  Central admin? Automated responses?
> Manual intervention? Are policies supported by your networking
> equipment?
> 
> *         Is security built-into your infrastructure or is it a bolt-on
> or an after-thought?
> 
> *         What is your corporate decision on what has priority, as well
> as the security position for voice, video and data
> 
> Let's just say there are a few things to think about, and I haven't
> addressed the processes and procedures around security recommendations.
> 
> Anne L. Coulombe
> 
> Director, Secure Convergence
> 
> Enterasys Networks
> 
> 
> -----Original Message-----
> From: Voipsec-bounces at voipsa.org [mailto:Voipsec-bounces at voipsa.org] On
> Behalf Of Mark Teicher
> Sent: Thursday, March 17, 2005 1:28 PM
> To: Voipsec at voipsa.org
> Subject: [VOIPSEC] Policy modifications for VOIP
> 
> it seems that organizations that is contemplating migrating to VOIP or
> has completed  a trial of VOIP may also want to examine modifications to
> their Business Continuity policies, since dial tone is no longer a TDM
> based issue.
> 
> What items needs to be examined in order to make certain changes to
> policies, procedures, processes for VOIP.??
> 
> What is the back up plan if network connectivity is lost by accident?
> For example, some big surly looking dude with a bum knee who may have
> just been woken from his work day nap (hard to find good security people
> these days)  as the VOIP vendor inserts changes into the network.   The
> surly guy upset rips out all the network wiring and then can't figure
> out why their is no dial tone, but yet the cross-connect wires look
> punched down correctly.
> 
> Understanding the changes to a network environment prior to trial and
> error is probably the first step in many security recommendations to a
> converged network.
> 
> 1. Business Continuity policy modifications (example above)
> 
> 2. Security policy modification
> 
> 3. .....
> 
> Can anyone think of others ??
> 
> _______________________________________________
> 
> Voipsec mailing list
> 
> Voipsec at voipsa.org
> 
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> 

-- 
Pankaj Shroff
shroffG at Gmail.com