[VOIPSEC] VoIP Attack : How feasible

Fri Jul 28 16:24:12 CDT 2006

It's not just the NAT, doing those lovely things, but of course NAT
plays a key part.

Having the NAT/DHCP/VPN services integrated and knoweldgeble of one
another plays another. Give thanks to some smart implementations from
a whole slew of vendors, the best of which of course focus on the
needs of the customer, not the orthodoxy of the experts.

Given these products NAT + PPTP are enough for most businesses and
work fine, but only if there is an ingres on the public internet and
only for incoming connections.

End-to-end betwen organizations on an ad-hoc basis? Nothing, and it's
our own fault for letting the anti-NAT bigots have their say in the
standards bodies and not shouting them down a decade ago.

We don't tell the world what to do.  If the world wants a billion
little NAT networks, the world will be a billion little NAT networks
and we must respect it and build around it at the standards and the
product level.

IPSEC?  I've never seen a deployment in any commercial environment
outside of toy trial, ever, and I've either been involved with,
reviewed or done analysis on well over a couple of thousand network
deployments over the years, from SME to F100.

Given that, anyone who says NAT is evil and should go away loses
credibility as it insults customers and real users with real needs and
doesn't take in to account that the reality is there for a good
reason.

My raspberry goes out to both technology purists and standards body
process queens. It especially goes out to people who think that the
internet was better before all those dumb users showed up.  We have
far too many of those people cluttering the industry as self-important
experts.

You can't get good technology when the system designers hate their customers.

Regards

M

On 7/28/06, Hallam-Baker, Phillip <pbaker at verisign.com> wrote:
> It works because the NAT boxes are doing weird and wonderful things beneath the covers that are a pig to implement, maintain and test.
>
> IPSEC is unfortunately quite broken. It is not a good VPN protocol though at one point we all assumed it would be.
>
> In particular the IPSEC group were completely indifferent to the issues NAT causes, they all had static IP addresses without NAT, they didn't care. The fact that the Internet would have come to a halt without NAT was completely beyond them.
>
>
> > -----Original Message-----
> > From: Voipsec-bounces at voipsa.org
> > [mailto:Voipsec-bounces at voipsa.org] On Behalf Of Michael Slavitch
> > Sent: Friday, July 28, 2006 3:19 PM
> > To: J. Oquendo
> > Cc: gdevine at cedarpointcom.com; voipsec at voipsa.org
> > Subject: Re: [VOIPSEC] VoIP Attack : How feasible
> >
> > 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
> > >
> >
> > _______________________________________________
> > Voipsec mailing list
> > Voipsec at voipsa.org
> > http://voipsa.org/mailman/listinfo/voipsec_voipsa.org
> >
> >
>