[55924] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

RE: VoIP over IPsec

daemon@ATHENA.MIT.EDU (Ejay Hire)
Mon Feb 17 13:58:39 2003

Date: Mon, 17 Feb 2003 12:58:03 -0600
From: "Ejay Hire" <ejay.hire@isdn.net>
To: "Charles  Youse" <cyouse@register.com>,
	"Stephen Sprunk" <stephen@sprunk.org>,
	"Charlie Clemmer" <cclemmer@nexgennetworks.com>
Cc: <nanog@merit.edu>
Errors-To: owner-nanog-outgoing@merit.edu


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.) =20

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

C. =20

-----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/f=
qos
_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


home help back first fref pref prev next nref lref last post