Re: VoIP over IPsec
On Tue, 18 Feb 2003, Petri Helenius wrote: Maybe a stupid question... why would you need GRE tunneling while IPsec has a tunnel mode of its own? Probably because a major router vendor, despite of repeated customer requests, declined to implement routing across such tunnel mode. So if the router uses tunnel mode (as per the RFC) despite the GRE tunnel the packet has three IP headers... So that's 160 bits ethernet layer 1 + 18 bytes ethernet layer 2 overhead, 24 bytes for the GRE tunnel, 20 bytes for the IPsec tunnel mode IP header, 10 - 12 bytes for the ESP header, 16 bytes for the initialization vector, 20 bytes for the original IP header and finally 20 bytes for the RTP header. With a 40 byte payload that adds up to 188 bytes on the wire of which 78% is overhead...
RE: VoIP over IPsec
Iljitsch van Beijnum wrote: So if the router uses tunnel mode (as per the RFC) despite the GRE tunnel the packet has three IP headers... So that's 160 bits ethernet layer 1 + 18 bytes ethernet layer 2 overhead, 24 bytes for the GRE tunnel, 20 bytes for the IPsec tunnel mode IP header, 10 - 12 bytes for the ESP header, 16 bytes for the initialization vector, 20 bytes for the original IP header and finally 20 bytes for the RTP header. With a 40 byte payload that adds up to 188 bytes on the wire of which 78% is overhead... ...leaving a dream of RTP as true and presumably light-weight protocol, as per rfc753, 759, 760, 761, 793, etc. Was this RTP the protocol under NVP (as per rfc741)? It was mentioned in documents before UDP (first mentioned in rfc755 and defined in rfc768), but I don't see any RFC ever defining it, and it doesn't have a protocol number assigned in the early assigned number RFCs (eg. rfc755, which is after UDP was conceived but before anything was removed or re-used from the early allocations). Of course that won't help the other overheads. And there's still a lot of the internet where you'd want to add cell tax then block up to the next 53 bytes... do we have 90% overhead yet? ;-) It's interesting that the original 'ST' and 'RTP' were thought of in 1979 and 1981, but it was 1990 before 'ST-II' (rfc1190) and 1996 by the time the actual RTP was formalized (rfc1889, where it is mentioned as being typically [..] on top of UDP, but the option is left open that it could be used directly as a protocol on top of IP). I'm sure I was using (commonly available) voice over the 'net before 1996, but I think it was a horrible application which sent duplicate UDP packets in the expectation of dropped packets... probably still with less overhead than today's VoIP over GRE over IPsec over EoMPLS over ATM type designs, despite the packet duplication... David.
RE: VoIP over IPsec
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Comments inline: At 01:34 PM 2/17/2003 -0500, Charles Youse wrote: 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? Oh goodness no. VoIP (SIP specifically) has no real security in it. Call hijacking for example is a matter of sending a pair of spoofed UDP packets to each phone and having the voice streams arrive at the attackers machine. Not pretty, and I do this trick (and worse) daily. (in a lab as part of work of course) What about sips:/TLS, S/MIME, and digest auth? These are all integral to the 'standard', and many popular implementations support these facilities currently. IPSec may be less painful within a single domain, but in other cases, I'd think that these facilities (or their derivatives) are the only practical option for 'real' security. Granted it is all pretty worthless if you dont enable/use any of it... Am I missing something? Regards, Andrew Bender taqua.com
RE: VoIP over IPsec
Well, sloppy thinking breeds complexity -- what I dislike about standards commitees (IETF/IESG included) is that they always sink to the lowest common denominator of the design talent or competence of its participants. In fact, a method to encrypt small parcels of data efficiently is well-known for decades. It is called stream cypher (surprise). Besides LFSR-based and other stream cyphers, any block cypher can be used in this mode. Its application to RTP is trivial and straight-forward. Just leave sequence number in clear text, so that position in the stream is recoverable in case of packet loss. It also allows precomputation of the key stream, adding nearly zero latency/jitter to the actual packet processing. --vadim On Wed, 19 Feb 2003, David Luyer wrote: ...leaving a dream of RTP as true and presumably light-weight protocol...
RE: VoIP over IPsec
On Tue, 18 Feb 2003, Petri Helenius wrote: Maybe a stupid question... why would you need GRE tunneling while IPsec has a tunnel mode of its own? Probably because a major router vendor, despite of repeated customer requests, declined to implement routing across such tunnel mode. So if the router uses tunnel mode (as per the RFC) despite the GRE tunnel the packet has three IP headers... So that's 160 bits ethernet layer 1 + 18 bytes ethernet layer 2 overhead, 24 bytes for the GRE tunnel, 20 bytes for the IPsec tunnel mode IP header, 10 - 12 bytes for the ESP header, 16 bytes for the initialization vector, 20 bytes for the original IP header and finally 20 bytes for the RTP header. With a 40 byte payload that adds up to 188 bytes on the wire of which 78% is overhead... --- On Crisco, if memory serves, default payload is 160 for G.711, not 40. The sizing goes in multiples of 80s. Thanks, Christian * The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers.
Re: VoIP over IPsec
Thus spake Vadim Antonov [EMAIL PROTECTED] In fact, a method to encrypt small parcels of data efficiently is well-known for decades. It is called stream cypher (surprise). Besides LFSR-based and other stream cyphers, any block cypher can be used in this mode. Its application to RTP is trivial and straight-forward. Just leave sequence number in clear text, so that position in the stream is recoverable in case of packet loss. Most stream modes are chained in some way to intentionally disrupt decryption if part of the ciphertext is missing; that is why IPsec resets the stream for each packet (currently). When NIST was standardizing AES, they added CTR mode specifically to address IPsec implementations. I think there's already been a draft out of the IRTF on how to modify IPsec for this, but it's not something I've followed closely. It also allows precomputation of the key stream, adding nearly zero latency/jitter to the actual packet processing. You fail to note that this requires precomputing and storing a keystream for every SA on the encrypting device, which often number in the thousands. This isn't feasible in a software implementation, and it's unnecessary in hardware. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
Re: VoIP over IPsec
On Crisco, if memory serves, default payload is 160 for G.711, not 40. The sizing goes in multiples of 80s. The increments go in 10ms. Default being 20ms or 30ms depending on your codec. Resulting data size obviously depends on this parameter and the codec. Quite many people compress their VoIP. (resulting in smaller payload) Pete
Re: VoIP over IPsec
On Tue, 18 Feb 2003, Stephen Sprunk wrote: In fact, a method to encrypt small parcels of data efficiently is well-known for decades. It is called stream cypher (surprise). Besides LFSR-based and other stream cyphers, any block cypher can be used in this mode. Its application to RTP is trivial and straight-forward. Just leave sequence number in clear text, so that position in the stream is recoverable in case of packet loss. Most stream modes are chained in some way to intentionally disrupt decryption if part of the ciphertext is missing; That would be CBC mode (where the output of one block becomes part of the input for the next) and I don't think this effect is a feature. At least, certainly not a desirable one because now we need a relatively large initialization vector in each encrypted packet. (It would of course be possible to negotiate some random data in advance from which the IVs can be taken in a way that is linked to the counter so the IV doesn't have to be included in the packet.) A stream cipher generates a random-looking data stream against which the payload is XORed. If you miss some payload you can still generate the data stream for the missing part and start XORing again for the data you have, as long as you exactly know how much is missing. This would be trivial to implement in IPsec with a fixed packet length because the anti-replay counter tells you the number of packets that were transmitted in the clear.
Re: VoIP over IPsec
On Tue, 18 Feb 2003, Stephen Sprunk wrote: It also allows precomputation of the key stream, adding nearly zero latency/jitter to the actual packet processing. You fail to note that this requires precomputing and storing a keystream for every SA on the encrypting device, which often number in the thousands. This isn't feasible in a software implementation, and it's unnecessary in hardware. You don' have to store the entire keystream, just enough to allow on-the-fly packet processing. Besides, memory is cheap. 100 msec buffers for 100,000 simultaneous voice connections is an astonishing 80 Mb. More realistically, it's 10k calls and 30 msec of buffering. --vadim
Re: VoIP over IPsec
On Mon, Feb 17, 2003 at 08:50:32AM +0200, Petri Helenius wrote: Are Cisco routers not happy doing VoIP/IPsec/GRE in concert? Cisco routers (and some others) are somewhat jittery doing IPsec but if you keep your CPU utilization levels low enough, it shouldn´t pose a problem. I would expect to keep watching the performance as traffic levels increase. Pete I've done voip over a pptp tunnel several different times with no real problems. This includes at hotels as well as at the last nanog. obviously there was no encryption.. but i'm not that exciting to listen to anyways ;-) - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
Re: VoIP over IPsec
In message 006401c2d655$abb5d560$93b58742@ssprunk, Stephen Sprunk writes: Thus spake Charles Youse [EMAIL PROTECTED] In order to cut costs in our telecom budget I'm toying with the idea of replacing a lot of our inter-office leased lines with VPN connections over the public Internet. [...] Assume for the moment that latency and bandwidth are not an issue; e.g., any two points that will be exchanging voice data will both have transit from the same provider with an aggressive SLA. Latency, bandwidth, and packet loss are moot. Jitter is VoIP's enemy. While jitter is more important, you can't ignore the others. The traditional phone network has long had a delay budget -- each component is supposed to bound how long it takes to process voice. Bandwidth matters, too, because the serialization delay for a packet increases the latency at that hop. This causes problems for compression and IPsec. You can get better compression -- and hence reduce bandwidth demands -- by compressing longer samples. Of course, this means that you can't finish the compression until the end of that time interval, which increases the latency. The obvious solution is to compress shorter segments, but that means that the IPsec overhead is a significant portion of the bandwidth consumed, which again has latency implications for bandwidth-limited channels. I'm not saying you can't do this; I am saying that under certain circumstances, there may be issues. Latency, for example, is a psychoacoustic phenomena (did you enjoy the last call you made over a satellite circuit? I didn't.) And yes, I had to crunch the numbers on this for my day job a few years ago. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of Firewalls book)
Re: VoIP over IPsec
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 At 01:24 AM 2/17/2003 -0600, Stephen Sprunk wrote: Unfortunately, IOS can introduce jitter when encrypting packets. To mitigate this, you can apply QOS, with a strict priotiy queue for the VoIP packets and the qos pre-classify feature. Your mileage will vary depending on the CPU power of the router, the traffic levels, and whether you're using hardware encryption. 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. -BEGIN PGP SIGNATURE- Version: PGP 8.0 iQA/AwUBPlEFb6vEtUU05riwEQKFDQCghB6q64UaJ6F4MnEy+c2byNuER48AoNG6 H/nd9NIhbueKUNvr3KboLRZ8 =7+qY -END PGP SIGNATURE-
Re: VoIP over IPsec
Thus spake Charlie Clemmer [EMAIL PROTECTED] 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 K5SSSdice at every possible opportunity. --Stephen Hawking
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:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 1:22 PM To: Charlie Clemmer Cc: [EMAIL PROTECTED] Subject: Re: VoIP over IPsec Thus spake Charlie Clemmer [EMAIL PROTECTED] 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 K5SSSdice at every possible opportunity. --Stephen Hawking
RE: VoIP over IPsec
Using hardware encryption with the qos pre-classify feature, I imagine that jitter will no longer be an issue - (that is, the jitter you mention previously is introduced by the lack of prioritization into the encryption queue). Or am I missing something? C. -Original Message- From: Stephen Sprunk [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 2:24 AM To: Charles Youse Cc: [EMAIL PROTECTED] Subject: Re: VoIP over IPsec Thus spake Charles Youse [EMAIL PROTECTED] In order to cut costs in our telecom budget I'm toying with the idea of replacing a lot of our inter-office leased lines with VPN connections over the public Internet. [...] Assume for the moment that latency and bandwidth are not an issue; e.g., any two points that will be exchanging voice data will both have transit from the same provider with an aggressive SLA. Latency, bandwidth, and packet loss are moot. Jitter is VoIP's enemy. Does anyone have any experience running VoIP over such tunnels? Is there a technical reason why this solution is not feasible? Are Cisco routers not happy doing VoIP/IPsec/GRE in concert? IPsec itself will not cause you problems; there's no theoretical conflict. Unfortunately, IOS can introduce jitter when encrypting packets. To mitigate this, you can apply QOS, with a strict priotiy queue for the VoIP packets and the qos pre-classify feature. Your mileage will vary depending on the CPU power of the router, the traffic levels, and whether you're using hardware encryption. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
RE: VoIP over IPsec
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:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 12:34 PM To: Stephen Sprunk; Charlie Clemmer Cc: [EMAIL PROTECTED] 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:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 1:22 PM To: Charlie Clemmer Cc: [EMAIL PROTECTED] Subject: Re: VoIP over IPsec Thus spake Charlie Clemmer [EMAIL PROTECTED] 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 K5SSSdice at every possible opportunity. --Stephen Hawking
Re: VoIP over IPsec
Does anyone have any experience running VoIP over such tunnels? Is there a technical reason why this solution is not feasible? Are Cisco routers not happy doing VoIP/IPsec/GRE in concert? The company I'm working for uses Shoreline VoIP PBX gear spread out over maybe a dozen offices of varying sizes. All are interconnected through the corporate enterprise net, Cisco routers with IPSEC/GRE tunnels over the public Internet. Each office has at least a T1, and we use a variety of providers. We have a typical mix of enterprise interoffice traffic: email, web, file sharing, etc. There's no QoS configured in the routers at present. It all seems to just work fine. Steve
Re: VoIP over IPsec
On Mon, 17 Feb 2003, Steve Feldman wrote: through the corporate enterprise net, Cisco routers with IPSEC/GRE tunnels over the public Internet. Maybe a stupid question... why would you need GRE tunneling while IPsec has a tunnel mode of its own?
Re: VoIP over IPsec
On Mon, 17 Feb 2003, Steve Feldman wrote: through the corporate enterprise net, Cisco routers with IPSEC/GRE tunnels over the public Internet. Maybe a stupid question... why would you need GRE tunneling while IPsec has a tunnel mode of its own? Probably because a major router vendor, despite of repeated customer requests, declined to implement routing across such tunnel mode. Pete
RE: VoIP over IPsec
Because you need to use GRE to create a virtual interface on the router and thus enable the use of routing protocols. At least, that's the only way I know how to do it. C. -Original Message- From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 6:19 PM To: Steve Feldman Cc: [EMAIL PROTECTED] Subject: Re: VoIP over IPsec On Mon, 17 Feb 2003, Steve Feldman wrote: through the corporate enterprise net, Cisco routers with IPSEC/GRE tunnels over the public Internet. Maybe a stupid question... why would you need GRE tunneling while IPsec has a tunnel mode of its own?
RE: VoIP over IPsec
More specifically, dynamic routing protocols like ospf and rip. -Original Message- From: Petri Helenius [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 5:21 PM To: Iljitsch van Beijnum; Steve Feldman Cc: [EMAIL PROTECTED] Subject: Re: VoIP over IPsec On Mon, 17 Feb 2003, Steve Feldman wrote: through the corporate enterprise net, Cisco routers with IPSEC/GRE tunnels over the public Internet. Maybe a stupid question... why would you need GRE tunneling while IPsec has a tunnel mode of its own? Probably because a major router vendor, despite of repeated customer requests, declined to implement routing across such tunnel mode. Pete
Re: VoIP over IPsec
More specifically, dynamic routing protocols like ospf and rip. There is no technical difference for running ospf and rip over IPsec tunnel or GRE tunnel. (other than the encapsulation itself) Implementations may (and do) force you to do suboptimal things because they are either designed or implemented way too long ago to make use of more recent technology in the most efficient fashion. Pete -Original Message- From: Petri Helenius [mailto:[EMAIL PROTECTED]] Sent: Monday, February 17, 2003 5:21 PM To: Iljitsch van Beijnum; Steve Feldman Cc: [EMAIL PROTECTED] Subject: Re: VoIP over IPsec On Mon, 17 Feb 2003, Steve Feldman wrote: through the corporate enterprise net, Cisco routers with IPSEC/GRE tunnels over the public Internet. Maybe a stupid question... why would you need GRE tunneling while IPsec has a tunnel mode of its own? Probably because a major router vendor, despite of repeated customer requests, declined to implement routing across such tunnel mode. Pete
RE: VoIP over IPsec
Comments inline: At 01:34 PM 2/17/2003 -0500, Charles Youse wrote: 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? Oh goodness no. VoIP (SIP specifically) has no real security in it. Call hijacking for example is a matter of sending a pair of spoofed UDP packets to each phone and having the voice streams arrive at the attackers machine. Not pretty, and I do this trick (and worse) daily. (in a lab as part of work of course) 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.) See above, SIP security sucks and H323 isn't much better. Has the issue of VoIP security ever been addressed? Not really. There are two parts to VoIP, the signalling and the bearer channel (actual RTP streams with the voice). The signalling channel is by far the easiest to abuse so if you are worried about security, go after this first. Encrypting the itty bitty RTP packets is a challenge that has yet to be entirely overcome, but encrypting the signalling is about 90% of the battle (according to me YMMV). So if you want this done without buying any new toys, and just using the Cisco's you have in place. Simply place a GRE tunnel between the two sites and just IPSec UDP port 5060 (SIP), and leave all other traffic alone (your phones are on separate subnets right???). This will encrypt the signalling (SIP is the assumption here) but leave the RTP alone so that you dont have the jitter issues (as much at least). If you are really serious about doing VoIP then look into the products from InGate and NetRake, and others. The InGate supports NAT/PAT (which is useful since some phones basically require a public IP address UGH), but more importantly it supports TLS. This encrypts the packets, but doesn't suffer from the keying issues of IPSec nor the overhead, so tiny little SIP packets can be encrypted without wait, but I am not clear on the RTP packets (they aren't encrypted as far as I know). Plus you get a registrar, proxy, etc, etc etc server along with it. They are relatively cheap. Netrake is for carriers, but is kinda cool to look at. As far as QoS, don't worry about it unless you are short on bandwidth, and even then it doesn't seem to make much difference (in my experience YMMV). Hope this helps I speak for me and me alone. Do not hold my employer liable for my rantings.
VoIP over IPsec
Hello again, I've heard a lot of encouraging things on this list in response to my previous inquiries about VoIP - hoping you can help me out again. In order to cut costs in our telecom budget I'm toying with the idea of replacing a lot of our inter-office leased lines with VPN connections over the public Internet. (I've got a lot of experience doing this in major production environments so I'm aware of the gotchas in this scenario.) My general method is to create IPsec-encrypted GRE tunnels between sites and then treat them as true virtual circuits; i.e., I run OSPF over the tunnel and exchange dynamic routing information, blah-de-blah. Assume for the moment that latency and bandwidth are not an issue; e.g., any two points that will be exchanging voice data will both have transit from the same provider with an aggressive SLA. Does anyone have any experience running VoIP over such tunnels? Is there a technical reason why this solution is not feasible? Are Cisco routers not happy doing VoIP/IPsec/GRE in concert? Thanks as always, C.
Re: VoIP over IPsec
Are Cisco routers not happy doing VoIP/IPsec/GRE in concert? Cisco routers (and some others) are somewhat jittery doing IPsec but if you keep your CPU utilization levels low enough, it shouldn´t pose a problem. I would expect to keep watching the performance as traffic levels increase. Pete
Re: VoIP over IPsec
Thus spake Charles Youse [EMAIL PROTECTED] In order to cut costs in our telecom budget I'm toying with the idea of replacing a lot of our inter-office leased lines with VPN connections over the public Internet. [...] Assume for the moment that latency and bandwidth are not an issue; e.g., any two points that will be exchanging voice data will both have transit from the same provider with an aggressive SLA. Latency, bandwidth, and packet loss are moot. Jitter is VoIP's enemy. Does anyone have any experience running VoIP over such tunnels? Is there a technical reason why this solution is not feasible? Are Cisco routers not happy doing VoIP/IPsec/GRE in concert? IPsec itself will not cause you problems; there's no theoretical conflict. Unfortunately, IOS can introduce jitter when encrypting packets. To mitigate this, you can apply QOS, with a strict priotiy queue for the VoIP packets and the qos pre-classify feature. Your mileage will vary depending on the CPU power of the router, the traffic levels, and whether you're using hardware encryption. S Stephen Sprunk God does not play dice. --Albert Einstein CCIE #3723 God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity. --Stephen Hawking
