hamachi p2p vpn nat-friendly protocol details

Travis H. wrote:
> On 2/24/06, Alex Pankratov <aphamachi.cc> wrote:
> 
>>Tero Kivinen wrote:

[snip]

>>>>The protocol description is missing some
details, so cannot say
>>>>anything about them (things like what is the
format of Ni, Nr, Gi, Gr
>>>>when sent over wire and when put to the
signatures etc, are the Gi, Gr
>>>>always the lenght of modulus (2048 bits)
etc).
>>
>>What would you like to know exactly ? The page was
not meant to
>>be a bit-level description of messages, merely a
description of
>>the security framework.
> 
> 
> Presumably he wants to make sure that the messages like
the following
> have an unambiguous interpretation:
> AUTH Identity Signature(Ni | Nr | Gi | Gr, Kpri_cli)
> Merely concatenating them is insufficient unless all
but one have a
> fixed length.
> I think a terse "unambiguous
representation" rationale is the whole
> reason for ASN.1, although it seems awfully complex for
such a simple
> goal.

Nonces and DH exponents are serialized using PER-style ASN.1
encoding.
So the whole concatenation is unambigious.

> I sort of wonder at the utility of a TCP implementation
of the p2p
> VPN... tunnelling TCP over TCP is well known to be a
Bad Thing with
> regard to interaction of the TCP timeouts.

Just to be clear, Hamachi tunnels VPN/P2P traffic over UDP.
TCP is
used for client-server session only.

VPN over TCP is bad for two reasons. One you listed, and
another
is that it becomes trivial to DoS this kind of VPN. TCP
packets
are not authenticated (unless MD5/BGP extension is used,
which
is unlikely), so the state of VPN transport layer and
consequently
the state of a tunnel can be altered by 3rd party.

That's why SSL VPNs make very little sense in non-proxied
setups
and that's why (I'd guess) OpenVPN 'tweaked' SSL to run
over UDP
instead.


------------------------------------------------------------
---------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe
cryptography" to majordomometzdowd.com