cwinfo/yggdrasil-go
5
0
Fork 0
mirror of https://github.com/cwinfo/yggdrasil-go.git synced 2024-11-10 00:30:26 +00:00
Code Releases Activity

Merge branch 'future' of https://github.com/yggdrasil-network/yggdrasil-go into future

Browse Source
This commit is contained in:
Arceliar 2021-07-03 17:27:13 -05:00
commit 92ef49987a
2 changed files with 35 additions and 65 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
CHANGELOG.md
View File

@ -27,58 +27,54 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
## [0.4.0] - 2021-07-04 ## [0.4.0] - 2021-07-04
### Added ### Added
- New routing scheme, which is backwards incompatible with previous versions of Yggdrasil
- The wire protocol version number, exchanged as part of the peer setup handshake, has been increased to 0.4
- Nodes running this new version **will not** be able to peer with earlier versions of Yggdrasil
- Please note that **the network may be temporarily unstable** while infrastructure is being upgraded to the new release
- TLS connections now use public key pinning - TLS connections now use public key pinning
- If no public key was already pinned, then the public key received as part of the TLS handshake is pinned to the connection - If no public key was already pinned, then the public key received as part of the TLS handshake is pinned to the connection
- The public key received as part of the handshake is checked against the pinned keys, and if no match is found, the connection is rejected - The public key received as part of the handshake is checked against the pinned keys, and if no match is found, the connection is rejected
### Changed ### Changed
- This version is backwards incompatible with previous versions of Yggdrasil - IP addresses are now derived from ed25519 public (signing) keys
- The wire protocol version number, exchanged as part of the peer setup handshake, has been increased to 0.4
- Nodes running this version will **not** be able to peer with earlier versions of Yggdrasil
- Please note that **the network may be temporarily unstable** while infrastructure is being upgraded to the new release
- Please also note that nodes may be removed from the public peers repository if they do not upgrade within some time period after release (perhaps a couple of weeks)
- IP addresses are derived from ed25519 public (signing) keys
- Previously, addresses were derived from a hash of X25519 (Diffie-Hellman) keys - Previously, addresses were derived from a hash of X25519 (Diffie-Hellman) keys
- Note that this means **all node addresses have changed with respect to previous releases**, so any existing services will be hosted at new addresses - Importantly, this means that **all internal IPv6 addresses will change with this release** — this will affect anyone running public services or relying on Yggdrasil for remote access
- The services page of the main repo has been updated to only list services in the new v0.4 network
- Service operators are encouraged to submit a PR if they wish to be (re-)added to the list
- It is now recommended to peer over TLS - It is now recommended to peer over TLS
- Link-local peers from multicast peer discovery will now connect over TLS, with the key from the multicast announcement pinned to the connection - Link-local peers from multicast peer discovery will now connect over TLS, with the key from the multicast beacon pinned to the connection
- `socks://` peers now expect the destination endpoint to be a `tls://` listener - `socks://` peers now expect the destination endpoint to be a `tls://` listener, instead of a `tcp://` listener
- Multicast peer discovery is now more configurable - Multicast peer discovery is now more configurable
- There are separate configuration options to control if beacons are sent, what port to listen on for incoming connections (if sending beacons), and whether or not to listen for beacons from other nodes (and open connections when receiving a beacon) - There are separate configuration options to control if beacons are sent, what port to listen on for incoming connections (if sending beacons), and whether or not to listen for beacons from other nodes (and open connections when receiving a beacon)
- Each configuration entry in the list specifies a regular expression to match against interface names - Each configuration entry in the list specifies a regular expression to match against interface names
- If an interface matches multiple regex in the list, it will use the settings for the first entry in the list that it matches with - If an interface matches multiple regex in the list, it will use the settings for the first entry in the list that it matches with
- The session and routing code has been redesigned and rewritten: - The session and routing code has been entirely redesigned and rewritten
- This is still an early work-in-progress, so the code hasn't been as well tested or optimized as the old code base. Please bear with us for these next few releases as we work through any bugs or issues - This is still an early work-in-progress, so the code hasn't been as well tested or optimized as the old code base — please bear with us for these next few releases as we work through any bugs or issues
- Generally speaking, we expect to see reduced bandwidth use and improved reliability with the new design, especially in mobile networks - Generally speaking, we expect to see reduced bandwidth use and improved reliability with the new design, especially in cases where nodes move around or change peerings frequently
- Cryptographic sessions no longer use a single shared (ephemeral) secret for the entire life of the session. Keys are now rotated regularly for ongoing sessions (both nodes will rotate keys at least once per round trip exchange of traffic, which is arguably *too* aggressive, we may throttle this somehow in a future release) - Cryptographic sessions no longer use a single shared (ephemeral) secret for the entire life of the session. Keys are now rotated regularly for ongoing sessions (currently rotated at least once per round trip exchange of traffic, subject to change in future releases)
- Source routing has been added. Under normal circumstances, this is what is used to forward session traffic (e.g. the user's IPv6 traffic) - Source routing has been added. Under normal circumstances, this is what is used to forward session traffic (e.g. the user's IPv6 traffic)
- DHT-based routing has been added. This is used when the sender does not know a source route to the destination. Forwarding through the DHT is less efficient, but the only information that it requires the sender to know is the destination node's (static) key. This is primarily used during the key exchange at session setup, or as a temporary fallback when a source route fails due to changes in the network - DHT-based routing has been added. This is used when the sender does not know a source route to the destination. Forwarding through the DHT is less efficient, but the only information that it requires the sender to know is the destination node's (static) key. This is primarily used during the key exchange at session setup, or as a temporary fallback when a source route fails due to changes in the network
- The new DHT design does not support crawling, and does not inherently allow nodes to look up the owner of an arbitrary key. In Yggdrasil, responding to lookups is implemented at the application level, and a response is only sent if the destination key matches the node's IP or /64 prefix - The new DHT design is no longer RPC-based, does not support crawling and does not inherently allow nodes to look up the owner of an arbitrary key. Responding to lookups is now implemented at the application level and a response is only sent if the destination key matches the node's `/128` IP or `/64` prefix
- The greedy routing scheme, used to forward all traffic in previous releases, is now only used for protocol traffic (i.e. DHT setup and source route discovery) - The greedy routing scheme, used to forward all traffic in previous releases, is now only used for protocol traffic (i.e. DHT setup and source route discovery)
- The code now lives in a [standalone library](https://github.com/Arceliar/ironwood). You are encouraged **not** to use it, as it's still considered pre-alpha, but it's available for those who want to experiment with the new routing algorithm in other contexts - The routing logic now lives in a [standalone library](https://github.com/Arceliar/ironwood). You are encouraged **not** to use it, as it's still considered pre-alpha, but it's available for those who want to experiment with the new routing algorithm in other contexts
- Session MTUs may be slightly lower now, in order to accommodate large packet headers if required
- Many of the admin functions available over `yggdrasilctl` have been changed or removed as part of rewrites to the code - Many of the admin functions available over `yggdrasilctl` have been changed or removed as part of rewrites to the code
- Several remote `debug` functions have been added temporarily, to allow for crawling and census gathering during the transition to the new version, but we intend to remove this at some point in the (possibly distant) future - Several remote `debug` functions have been added temporarily, to allow for crawling and census gathering during the transition to the new version, but we intend to remove this at some point in the (possibly distant) future
- The list of available functions will likely be expanded in future releases - The list of available functions will likely be expanded in future releases
- The configuration file format has been updated in response to the changed/removed features - The configuration file format has been updated in response to the changed/removed features
### Removed ### Removed
- TunnelRouting (aka cryptokey routing) has been removed - Tunnel routing (a.k.a. crypto-key routing or "CKR") has been removed
- It was too easy to accidentally break routing by capturing the route to peers with the tun adapter - It was far too easy to accidentally break routing altogether by capturing the route to peers with the TUN adapter
- We recommend tunneling an existing standard over Yggdrasil instead (e.g. `ip6gre` and `ip6gretap`) - We recommend tunnelling an existing standard over Yggdrasil instead (e.g. `ip6gre`, `ip6gretap` or other similar encapsulations, using Yggdrasil IPv6 addresses as the tunnel endpoints)
- SessionFirewall has been removed - All `TunnelRouting` configuration options will no longer take effect
- This was never a true firewall, it was simply a way to prevent a node from being flooded with unwanted sessions, so the name could be misleading and lead to a false sense of security - Session firewall has been removed
- Due to design changes, the new code needs to address the possible memory exhaustion attacks in other ways, and a single configurable list no longer makes sense - This was never a true firewall — it didn't behave like a stateful IP firewall, often allowed return traffic unexpectedly and was simply a way to prevent a node from being flooded with unwanted sessions, so the name could be misleading and usually lead to a false sense of security
- Due to design changes, the new code needs to address the possible memory exhaustion attacks in other ways and a single configurable list no longer makes sense
- Users who want a firewall or other packet filter mechansim should configure something supported by their OS instead (e.g. `ip6tables`) - Users who want a firewall or other packet filter mechansim should configure something supported by their OS instead (e.g. `ip6tables`)
- SIGHUP handling has been removed - All `SessionFirewall` configuration options will no longer take effect
- Previously, we set a custom SIGHUP handler, and used it to reload (parts of) the config file - `SIGHUP` handling to reload the configuration at runtime has been removed
- It was never obvious which parts could be reloaded while live, and which required the application to be killed and restarted to take effect - It was not obvious which parts of the configuration could be reloaded at runtime, and which required the application to be killed and restarted to take effect
- Reloading the config without restarting was also a delicate and bug-prone process, and was distracting from more important developments - Reloading the config without restarting was also a delicate and bug-prone process, and was distracting from more important developments
- SIGHUP will be handled normally (i.e. by exiting) - `SIGHUP` will be handled normally (i.e. by exiting)
- The `doc` folder has been removed
- In light of the routing scheme's redesign and reimplementation, the documentation was out out-of-date
- New documentation may be added in a future release
- `cmd/yggrasilsim` has been removed, and is unlikely to return to this repository - `cmd/yggrasilsim` has been removed, and is unlikely to return to this repository
## [0.3.16] - 2021-03-18 ## [0.3.16] - 2021-03-18

44
README.md
View File

@ -11,37 +11,14 @@ allows pretty much any IPv6-capable application to communicate securely with
other Yggdrasil nodes. Yggdrasil does not require you to have IPv6 Internet other Yggdrasil nodes. Yggdrasil does not require you to have IPv6 Internet
connectivity - it also works over IPv4. connectivity - it also works over IPv4.
Although Yggdrasil shares many similarities with
[cjdns](https://github.com/cjdelisle/cjdns), it employs a different routing
algorithm based on a globally-agreed spanning tree and greedy routing in a
metric space, and aims to implement some novel local backpressure routing
techniques. In theory, Yggdrasil should scale well on networks with
internet-like topologies.
## Supported Platforms ## Supported Platforms
We actively support the following platforms, and packages are available for Yggdrasil works on a number of platforms, including Linux, macOS, Ubiquiti
some of the below: EdgeRouter, VyOS, Windows, FreeBSD, OpenBSD and OpenWrt.
- Linux Please see our [Installation](https://yggdrasil-network.github.io/installation.html)
- `.deb` and `.rpm` packages are built by CI for Debian and Red Hat-based page for more information. You may also find other platform-specific wrappers, scripts
distributions or tools in the `contrib` folder.
- Arch, Nix, Void packages also available within their respective repositories
- macOS
- `.pkg` packages are built by CI
- Ubiquiti EdgeOS
- `.deb` Vyatta packages are built by CI
- Windows
- FreeBSD
- OpenBSD
- OpenWrt
Please see our [Platforms](https://yggdrasil-network.github.io/platforms.html) pages for more
specific information about each of our supported platforms, including
installation steps and caveats.
You may also find other platform-specific wrappers, scripts or tools in the
`contrib` folder.
## Building ## Building
@ -97,21 +74,18 @@ by giving the Yggdrasil binary the `CAP_NET_ADMIN` capability.
## Documentation ## Documentation
Documentation is available on our [GitHub Documentation is available [on our website](https://yggdrasil-network.github.io).
Pages](https://yggdrasil-network.github.io) site, or in the base submodule
repository within `doc/yggdrasil-network.github.io`.
- [Configuration file options](https://yggdrasil-network.github.io/configuration.html) - [Installing Yggdrasil](https://yggdrasil-network.github.io/installation.html)
- [Platform-specific documentation](https://yggdrasil-network.github.io/platforms.html) - [Configuring Yggdrasil](https://yggdrasil-network.github.io/configuration.html)
- [Frequently asked questions](https://yggdrasil-network.github.io/faq.html) - [Frequently asked questions](https://yggdrasil-network.github.io/faq.html)
- [Admin API documentation](https://yggdrasil-network.github.io/admin.html)
- [Version changelog](CHANGELOG.md) - [Version changelog](CHANGELOG.md)
## Community ## Community
Feel free to join us on our [Matrix Feel free to join us on our [Matrix
channel](https://matrix.to/#/#yggdrasil:matrix.org) at `#yggdrasil:matrix.org` channel](https://matrix.to/#/#yggdrasil:matrix.org) at `#yggdrasil:matrix.org`
or in the `#yggdrasil` IRC channel on Freenode. or in the `#yggdrasil` IRC channel on [libera.chat](https://libera.chat).
## License ## License