Home page logo
/

nanog logo nanog mailing list archives

RE: VoIP over IPsec
From: "Ejay Hire" <ejay.hire () isdn net>
Date: Mon, 17 Feb 2003 12:58:03 -0600


There is some work on the SRTP protocol, but finding a cpe that will work with it is unlikely in the near future.  If 
you had a gateway server at each site then you might be able to use a back-to-back ua and srtp between the sites.  
(That sounds kludgey.

-----Original Message-----
From: Charles Youse [mailto:cyouse () register com]
Sent: Monday, February 17, 2003 12:34 PM
To: Stephen Sprunk; Charlie Clemmer
Cc: nanog () merit edu
Subject: RE: VoIP over IPsec



So do you suppose that in my scenario, I'd be better off leaving the VoIP out of the encrypted tunnels and use a 
separate [cleartext] path for them?

I'm worried about the security implications, not because I feel there is a huge security risk but because I'm sure the 
topic will be brought up.  (Communicating over one provider's backbone provides little opportunity for third parties to 
snoop packets between points, of course.)  

Has the issue of VoIP security ever been addressed?  I suppose I should really do my homework.

C.  

-----Original Message-----
From: Stephen Sprunk [mailto:stephen () sprunk org]
Sent: Monday, February 17, 2003 1:22 PM
To: Charlie Clemmer
Cc: nanog () merit edu
Subject: Re: VoIP over IPsec



Thus spake "Charlie Clemmer" <cclemmer () nexgennetworks com>
Stephen, I know this is outside of Charles' original inquiry, but I'm not
familiar with this "qos pre-classify" feature. Since we would be
encrypting
voice traffic ... at what point would you classify it? If I classify it
before it goes into the tunnel and gets encrypted, would that
classification last once it's encrypted? If we try to classify after it's
been encrypted, how can we tell it's voice traffic? It seems to me that
jitter from both the actual encryption process as well as that associated
with basic serialization would be the potential death of VoIP in this
scenario, but I'm not sure mechanisms available to help resolve that risk.

In the default IOS code path, encryption happens before QOS (and after GRE).
Modern IOS versions copy the DSCP when encapsulating/ encrypting packets, so
DSCP-based QOS will still work, but IP- and port-based QOS will not.

More importantly, encryption is slow; even hardware encryption is
significantly slower than the rest of the forwarding process.  It's also
FIFO by default, meaning that large data packets can get stuck ahead of your
VoIP packets, causing jitter.

'qos pre-classify' adds a second QOS stage before encryption, which allows
you to classify packets in their unencrypted state and, more importantly,
adds PQ capability to the encryption stage.

For more information:
http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fqos
_c/fqcprt1/qcfvpn.htm

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]