[VOIPSEC] VoIP Attack : How feasible

[J. Oquendo]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1



On Fri, 28 Jul 2006 13:02:26 -0400 Geoff Devine
<gdevine at cedarpointcom.com> wrote:
>VPNs are excellent at dealing with NAT traversal.  The issue at
>the
>moment is that Microsoft has not implemented header suppression
>for RTP
>which would make VoIP over VPN work efficiently.  When we have a
>Micro$oft release that does this, the entire industry will follow.

Maybe we see things different from non engineers. But NAT + VPN's
are not an excellent choice.

NAT+VPN 101

1) NAT changes the IP address of the internal computer to that of
the NAT device. IKE embeds the sending computer’s IP address in its
payload, and this embedded address doesn’t match the source address
of the IKE packet (which is that of the NAT device). When this
happens (address mismatch) what do you think will happen...

2) TCP checksums are used to verify the packets. The checksum is in
the TCP header and it contains the IP addresses of the sending &
receiving addresses along with the port numbers used for the
communications... With normal NAT this isn’t a problem because the
NAT device updates the headers to show its own address and port in
place of the sending device. Remember IPSec encrypts the headers
with ESP protocol...

Since the header is encrypted, NAT can’t change it which means the
checksum is invalid, so the receiving computer rejects the packet.
NAT isn’t able to use the port numbers in TCP and UDP headers to
multiplex packets to multiple NAT'ed computers when those headers
have been encrypted by ESP...

As for MS... NAT-T

http://www.ietf.org/rfc/rfc3948.txt
http://www.ietf.org/rfc/rfc3947.txt

>---------------------------------------------------
>From: Simon Horne <s.horne at packetizer.com>
>Subject: Re: [VOIPSEC] VoIP Attack : How feasible
>
>The problem with VPN's is they are notoriously difficult to
>configure
>and
>deploy and I abandoned them 4 years ago to find a better and more
>easily
>
>deployable solution.
>
>He's my points on the topic.
>VPNs do not provide end to end authentication.
>They only provide from you to the next hop and even then you
>cannot
>verify
>the callers authentication credentials within the VoIP client. The
>only
>way
>you can provide end-to-end authentication is to embed the
>authentication
>
>information into the call signalling so it goes end to end. Now in
>some
>protocols this is easy as there is a end to end call signalling
>channel
>(which can optionally be routed) and a standard framework to carry
>these
>
>messages. The ability to do this is further complicated with
>protocols
>who
>prefer to do signalling over UDP which cannot handle the large
>message
>sizes required to carry the security credentials.
>
>VPNs do not provide end to end encryption.
>They provide only to the next hop and then has to decrypt and re-
>encrypt
>
>for the next hop. There already is much better solution like SRTP,
>ZRTP
>or
>just encrypted RTP etc which do not require the extra burden
>required on
>
>the hop. The fact that some protocols have no standard framework
>to
>exchange key material makes wholesale interoperable, ubiquitous
>deployment
>of encrypted media services into existing networks near impossible
>
>resulting in the need for intersite VPN's. This is very much a
>protocol
>issue.
>
>VPNs do not provide efficient NAT Traversal.
>It is my opinion that the choice of VPN for NAT traversal should
>be last
>
>resort. Protocols that use symmetric RTP have particular problems
>traversing NAT which excludes methods like UPnP from being a
>functional
>solution and greatly complicates NAT detection and traversal
>mechanisms.
>
>There are already well know standards in some protocols (and more
>in
>development) for efficient NAT traversal without resorting to
>requiring
>a
>peer to peer architecture.
>
>In 10 years of VoIP NAT and security development and after
>truckloads of
>
>publicized RFC's and white papers why are we still talking about
>VPN's?
>Surely there must be better solutions that can be deployed today.
>There
>is,
>just they are not available in SIP.
>
>
>_______________________________________________
>Voipsec mailing list
>Voipsec at voipsa.org
>http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
perl -e 'print $i=pack(c5,(40*2),sqrt(7600),(unpack(c,Q)-3+1+3+3-
7),oct(104),10,oct(101));'
-----BEGIN PGP SIGNATURE-----
Note: This signature can be verified at https://www.hushtools.com/verify
Version: Hush 2.5

wpwEAQECAAYFAkTKRpIACgkQVnroYexO+HKJ5AQAmY7THWUgsQC3alojIcZ9mktw9NLv
gumQhOsToaIf5YrLueFbhp1McrJocZF/WZ5rSQSgdyvTbZ89OUY1jx8oohQinsml/ufe
GjdqE3SfpU1Y79JCCAMHKZpLrAWdfVSHXvDtf37WJ57PvAu57Ccs5jI+ZKJvVqVyAqQI
+ZT3Z0w=
=rbnv
-----END PGP SIGNATURE-----




Concerned about your privacy? Instantly send FREE secure email, no account required
http://www.hushmail.com/send?l=480

Get the best prices on SSL certificates from Hushmail
https://www.hushssl.com?l=485