hamachi p2p vpn nat-friendly protocol details

[Alex Pankratov]

Travis H. wrote:
> On 2/24/06, Alex Pankratov <ap at hamachi.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 majordomo at metzdowd.com