gitea-mirror/rosenpass
1
0
Fork 0
mirror of https://github.com/rosenpass/rosenpass.git synced 2025-12-12 07:40:30 -08:00
Code Issues Packages Projects Releases Wiki Activity

Merge branch 'main' into feat/cookie-mechanism, ignore incoming messages when initiator is under load, whitepaper updates

Browse Source
This commit is contained in:
Prabhpreet Dua
2023-11-29 05:06:22 +05:30
parent 96d4f0b545 d539be3142
commit 2ae3d6c271
58 changed files with 3080 additions and 577 deletions
Download Patch File Download Diff File Expand all files Collapse all files

41
papers/whitepaper.md
View File

@@ -430,27 +430,31 @@ ICR5 and ICR6 perform biscuit replay protection using the biscuit number. This i
### Denial of Service Mitigation and Cookies
Rosenpass derives its cookie-based DoS mitigation technique from Wireguard [INSERT REFERENCE HERE]. When the client is under load, it may choose to not process further handshake messages, but instead to respond with a cookie reply message (see Fig. 2- Rosenpass Message Types).
Rosenpass derives its cookie-based DoS mitigation technique for a responder from Wireguard [@wg].
When the responder is under load, it may choose to not process further handshake messages, but instead to respond with a cookie reply message (see Figure \ref{img:MessageTypes}).
The sender of the exchange then uses this cookie in order to resend the message and have it accepted the following time by the reciever.
For an initiator, Rosenpass ignores the message when under load.
#### Cookie Reply Message
The cookie reply message consists of the `sid` of the client under load, a random 24-byte bitstring `nonce` and an encrypted `cookie` reply field which consists of the following (from the perspective of the cookie reply sender):
The cookie reply message consists of the `sid` of the client under load, a random 24-byte bitstring `nonce` and encrypting `cookie_tau` into a `cookie` reply field which consists of the following (from the perspective of the cookie reply sender):
```
tau = lhash("cookie-tau",r_m, a_m)[0..16]
cookie = XAEAD(lhash("cookie-key", spkm), nonce, tau , mac_peer)
cookie_tau = lhash("cookie-tau",r_m, a_m)[0..16]
cookie = XAEAD(lhash("cookie-key", spkm), nonce, cookie_tau , mac_peer)
```
where `r_m` is a secret variable that changes every two minutes to a random value. `a_m` is a concatenation of the source IP address and UDP source port of the client's peer. `mac_peer` is the `mac` field of the peer's handshake message to which this is the reply.
where `r_m` is a secret variable that changes every two minutes to a random value. `a_m` is a concatenation of the source IP address and UDP source port of the client's peer. `cookie_tau` will result in a truncated 16 byte value from the above hash operation. `mac_peer` is the `mac` field of the peer's handshake message to which message is the reply.
#### Envelope `mac` Field
Similar to `mac.1` in Wireguard handshake messages, the `mac` field of a Rosenpass envelope from a handshake packet sender's point of view consists of the following:
```
mac = lhash("mac", spkt, MAC_WIRE_DATA)
mac = lhash("mac", spkt, MAC_WIRE_DATA)[0..16]
```
where `MAC_WIRE_DATA` represents all bytes of msg prior to `mac` field in the envelope.
@@ -459,7 +463,7 @@ If a client receives an invalid `mac` value for any message, it will discard the
#### Envelope cookie field
The cookie content sent in the cookie reply message is used by the sender derive a `cookie` field in the sender's message envelope to retransmit the handshake message. This is the equivalent of Wireguard's `mac.2` field and is determined as follows:
The `cookie_tau` value encrypted as part of `cookie` field in the cookie reply message is decrypted by its receiver and stored as the `last_recvd_cookie` for a limited time (120 seconds). This value is then used by the sender to append a `cookie` field to the sender's message envelope to retransmit the handshake message. This is the equivalent of Wireguard's `mac.2` field and is determined as follows:
```
@@ -471,7 +475,7 @@ else {
}
```
where `last_recvd_cookie` is the last received `cookie` field from a cookie reply message by a hanshake message sender, `last_cookie_time_ellapsed` is the amount of time in seconds ellapsed since last cookie was received, and `COOKIE_WIRE_DATA` are the message contents of all bytes of this message prior to the `cookie` field.
Here, `last_recvd_cookie` is the last received decrypted data of the `cookie` field from a cookie reply message by a hanshake message sender, `last_cookie_time_ellapsed` is the amount of time in seconds ellapsed since last cookie was received, and `COOKIE_WIRE_DATA` are the message contents of all bytes of the retransmitted message prior to the `cookie` field.
The sender can use an invalid value for the `cookie` value, when the receiver is not under load, and the receiver must ignore this value.
However, when the receiver is under load, it may reject messages with the invalid `cookie` value, and issue a cookie reply message.
@@ -480,10 +484,17 @@ However, when the receiver is under load, it may reject messages with the invali
Rosenpass implementations are expected to detect conditions in which they are under computational load to trigger the cookie based DoS mitigation mechanism by replying with a cookie reply message.
For the reference implemenation,
For the reference implemenation, Rosenpass has derived inspiration from the linux implementation of Wireguard.
This implementation suggests that the reciever keep track of the number of messages it is processing at a given time.
On receiving an incoming message, if the length of the message queue to be processed exceeds a threshold `MAX_QUEUED_INCOMING_HANDSHAKES_THRESHOLD`, the client is considered under load and its state is stored as under load. In addition, the timestamp of this instant when the client was last under load is stored. When recieving subsequent messages, if the client is still in an under load state, the client will check if the time ellpased since the client was last under load has exceeded `LAST_UNDER_LOAD_WINDOW` seconds. If this is the case, the client will update its state to normal operation, and process the message in a normal fashion.
Currently, the following constants are derived from the Linux kernel implementation of Wireguard:
```
TDB- add mechanism
MAX_QUEUED_INCOMING_HANDSHAKES_THRESHOLD = 4096
LAST_UNDER_LOAD_WINDOW = 1 //seconds
```
## Dealing with Packet Loss
@@ -494,15 +505,11 @@ The responder does not need to do anything special to handle RespHello retransmi
### Interaction with cookie reply system
When a peer is under load, a handshake message (be it from the initiator and the responder) may be discarded and a cookie reply message sent.
The cookie reply system does not interfere with the retransmission logic discussed above.
#### Initiator
When the initator is under load, it will ignore processing any incoming messages.
On reciept of the cookie reply message, which will enable the peer to send a retransmitted InitHello or InitConf message with a valid `cookie` value that will not be discarded, the peer will resend the message as per retransmission logic listed above.
#### Responder
On a reciept of a cookie reply message, the responder should wait for a retranmission of `InitHello` or `InitConf` messages and respond with the above retranmission logic with the `cookie` value appended.
When a responder is under load, a handshake message will be discarded and a cookie reply message is sent. The initiator, then on the reciept of the cookie reply message, will store a decrypted `cookie_tau` value to use when appending a `cookie` to subsequently sent messages. As per the retransmission mechanism above, the initiator will send a retransmitted InitHello or InitConf message with a valid `cookie` value appended. On receiving the retransmitted handshake message, the responder will validate the `cookie` value and resume with the handshake process.
\printbibliography