search for: metagraph

While working on SPTPS UDP relaying I realized that there is one issue I didn't account for, which is that the sending node only knows the PMTU to the first relay node. It doesn't know the PMTU of the entire relay path beyond the first hop, because the relay nodes don't provide their own PMTU information over the metaprotocol. Now, in the legacy protocol this is not really an issue,

> If your question is "can I assign the same subnet to multiple tinc > nodes on the same network", the answer is yes (for both 1.0 and 1.1). Yes exactly. > currently it tries to estimate which one is closest by measuring the > time it took to establish metaconnections along the edges to the node, Shure? I remember alphabetic order (host name) in tinc 1.0. Is it the same

...taconnections along the edges to the node, > > Shure? I remember alphabetic order (host name) in tinc 1.0. Actually, yes you're right, my bad, I was confused between edge_t::weight and subnet_t::weight while looking at the code. The edge weight is only used when routing messages over the metagraph, not when sending packets. You are correct that node name lexicographical order is used as priority order as a last resort. However, you can add a weight to your Subnet configuration to customize the priority. You might want to look at the documentation for the Subnet configuration option in the m...

On 09/03/2016 10:56 AM, Etienne Dechamps wrote: > C will still need keys in order to establish metaconnections with A and B (as > well as a few other things). However there is no need for C to own any > "Subnets" at all. If somebody breaks into C, he could get access to the vpn network, right? Because the keys are there, it will be possible to use them to get access. Even if

...ding keys: - The key used for the metaconnections (routing protocol over TCP) - i.e. the one you configure in your host files - is NOT the same as the key used for UDP data tunnels. - The key for data tunnels is negotiated over the metaconnections, by sending REQ_KEY and ANS_KEY messages over the metagraph (i.e. the graph of metaconnections). So, in your example, B will send a REQ_KEY message to A, which will forward it to C, which will respond with an ANS_KEY message, also forwarded through A. - These "data keys" are generated on-the-fly and are ephemeral, with an expiry time set by the K...

...future. In any case, I should probably mention that, to the best of my knowledge (Guus might be able to confirm), right now tinc is mostly designed to protect from attacks coming from *outside* the VPN (as in, outside the web of metaconnections). Protecting against insider attacks (from inside the metagraph) doesn't get anywhere near as much attention. This means it is more likely that there are vulnerabilities lurking in the code that we're not aware of. Compared to an outside attacker, an inside attacker has a much larger attack surface to exploit because they can send arbitrary messages thr...

Hi all! I still have never managed to fully wrap my head around how UDP data tunnels can be established between nodes. Everytime I think I understand it, I see something that confuses me again Just now I am seeing the following: I have nodes A, B + C A has everybody's keys and host configuration files. B and C only have A's key, and host config with A's public IP address. B and

TL;DR: a proposal for a new tinc feature that allows nodes to filter ADD_SUBNET messages based on the metaconnection on which they are received, so that nodes can't impersonate each other's VPN Subnets. Similar to StrictSubnets in spirit, but way more flexible. BACKGROUND: THE ISSUE OF TRUST IN A TINC NETWORK In terms of metaconnections (I'm not discussing data tunnels here), one of