[VOIPSEC] VoIP Attack : How feasible

[Michael Slavitch]

Nu? The VPN creates an overlay network which is an extension of the
network, the NAT addresses are out of the equation.

Please explain why I can read this message and take phone calls
between two natted networks over a VPN.

Your assertion that it doesn't work doesn't mesh with reality.

You connect, run the session and it works.  This harping about ipsec
and checksums is insane theory by ipsec bigots.

It works in the field now in broad use worldwide.



On 7/28/06, J. Oquendo <joquendo at hushmail.com> wrote:
> -----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
>
>
> _______________________________________________
> Voipsec mailing list
> Voipsec at voipsa.org
> http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
>