... | ... | @@ -11,10 +11,10 @@ We assume that the client has taken and verified the DNSSEC data as described in |
|
|
|
|
|
In this example the client will connect to **example.com**
|
|
|
|
|
|
Fenrir supports 2 connection algorithms:
|
|
|
* **3 Round-Trip**: full perfect forward security per each connection. used for authenticated connections.
|
|
|
* **2 Round-Trip**: QUIC-like, less rigid forward security. used for anonymous connections, since there is not much to protect anyway.
|
|
|
* A **1-RT** minimaLT-style is possible, but will probably be implemented only in the future.
|
|
|
Fenrir supports 3 connection algorithms:
|
|
|
* **Full Security** (3 Round-Trip): full perfect forward security per each connection. used for authenticated connections.
|
|
|
* **Stateful** (2 Round-Trip): [QUIC](QUIC)-like, less rigid forward security. used for anonymous connections, since there is not much to protect anyway.
|
|
|
* **Directory-synchronized** (1 Round-Trip) minimaLT-style is possible, but will probably be implemented only in the future.
|
|
|
|
|
|
Every connection can be either anonymous or authenticated, and when switching from an anonymous connection to an user authenticated one a new key exchange **must** take place, to better protect the authentication data.
|
|
|
|
... | ... | @@ -23,17 +23,17 @@ Every connection can be either anonymous or authenticated, and when switching fr |
|
|
|
|
|
## AS database
|
|
|
|
|
|
The AS need a (small) database with at least the following information for each Service:
|
|
|
The AS needs a (small) database with at least the following information for each Service:
|
|
|
* Service **fqdn** (example.com)
|
|
|
* Service priority (0-255)
|
|
|
* Service preference (0-255)
|
|
|
* Service id (random 16 bits)
|
|
|
* Service secret key (128/256bit key)
|
|
|
* Service token (256bit random)
|
|
|
|
|
|
This information permits us to:
|
|
|
* decide where the client will connect
|
|
|
* support multiple servers
|
|
|
* support fallback servers.
|
|
|
* support multiple servers for each service
|
|
|
* support fallback servers / load balancing
|
|
|
|
|
|
In the future filters based on countries or other client-provided information might be added easily.
|
|
|
|
... | ... | @@ -253,10 +253,6 @@ Which means that somehow we need to be able to make this exchange a multi-packet |
|
|
|
|
|
## Multi-packet key exchange:
|
|
|
|
|
|
I'm alway open to suggestions, but for now the only thing that comes to mind is that we can use the first byte to use additional "fragmented key exchange" packets.
|
|
|
This is not yet supported and has not received much though. Using random nonces and the content of the stream ids and counters we can handle multi-packet key agreement. This however brings more burden to the authentication server and should only be supported on the full-security handshake, as that is the only one that requires at least one round trip to check the validity of the source ip.
|
|
|
|
|
|
This however is a little problem, because the server now need to buffer the packets and wait for them, which might open the door to DoS attacks.
|
|
|
|
|
|
To mitigate those attacks the server might refuse to acknowledge fragmented packets of less than 1280 bytes and have very little timeouts (1 second) for buffer reconstruction, but the solution is not defined for now.
|
|
|
|
|
|
Again, if you have ideas, just tell me :) |
|
|
---- |
|
|
\ No newline at end of file |