blizzard_dtn_draft.md

☃️ Blizzard ☃️: Delightfully simple DTN protocol

Blizzard is a delay-tolerant protocol for setting up authenticated and encrypted channels.It is designed to be used in peer-to-peer networks where peers are not necessarily online at the same time.

Unlike most other DTN protocols, it is designed to be used on resource-constrained and embedded devices like microcontrollers. This crate is no_std-compatible. However, it does require an external allocator.

The core Blizzard crate is built on top of a no_std-compatible fork of snow, a noise protocol implementation.

Features

To the best of my knowledge, Blizzard offers:

• Simplicity. Reading the entire Blizzard codebase is an afternoon project, no more. The Blizzard codebase is written to be human readable within an afternoon.
• Initiator anonymity. Nobody outside Outside observers of a channel is are not able to determine any long-term identifiers associated with the initiator of any a new channel.
• Limited protection of recipient identity. Identifying yourself as the recipient of a message doesn't reveal any long-term identifiers about associated with yourself you.
• Forward secrecy. Each channel (not message) uses a new ephemeral key. Rekeying/ratcheting is planned but not currently supported. In the future support for rekeying/ratcheting will be added.
• Authenticated and encrypted channels. (nobody Nobody outside of a channel can forge send==(I think?)== or read messages in a channel~~)~~.
• Support for initial contact through a pre-shared one-time address.
• Difficult, but not impossible, Increased difficulty in location tracking of peers. More details about this in the section on routing.
• Flexible operation and deployment. Runs Can run over any physical link with an MTU of at least 240 bytes.

Given the following Assumptions assumptions: * These properties will break down if the IK handshake pattern of the noise protocol framework is broken, or if your private keys are obtained by an attacker.

• The IK handshake pattern of the noise protocol framework is not broken
• A user's private keys have not been obtained by an attacker

Non-goals

Blizzard is not tolerant of sybil attacks, black-holing, or other malicious denial-of-service type behavior. Network operation is predicated on the assumption that peers are honest and will not attempt to disrupt the network, acting in good faith. hHowever, bad actors should not be capable of compromising the security or anonymity guarantees of the protocol. ==(I would say "there are no plans to make Blizzard tolerant to these attacks" here and leave it at that)==

The reason Blizzard doesn't solve these issues, other than the fact that they're hard to solve, the rationale for this decision is that they~~'~~ are mostly an academic concern. In addition they are hard to solve. If someone is in a position to can DoS a delay tolerant network, they~~'~~ are usually in a position able to do it in a variety of ways using a variety of methods; and thus stopping their attack is not feasible. Often , in the real world, you can mitigate an attack at the protocol layer, but your attackers can will simply move their attack to the physical layer without any loss in efficacy. ==(This paragraph doesn't seem super necessary)==

Blizzard does not handle any transport layer concerns. It is up to the user to send and receive messages over a transport. Blizzard messages can be sent over any transport, including unreliable transports like UDP, but it is currently up to the user to handle message ordering and retransmission if their application requires those things. This may change in the future.

Future goals

• While mitigating an intentional DoS attack is a non-goal, it would be nice to add some sort of airtime fairness controls for honest peers to ensure QoS.
• Channels should at some point be able to coordinate re-keying according to the noise spec, but for now symmetric session keys are long-lived.

Routing overview

Routing in Blizzard uses a slightly modified binary spray and wait scheme called stochastic binary spray and wait.

Normal spray and wait operates by proactively "spraying" a limited number of copies of a message across the network, then "waiting" for the bearer of one of those copies to come across its recipient and deliver it. In specific Bbinary spray and wait, specifically, operates by requiring that peers give away half of their assigned "copies" of the messages they know about ==(could you also describe it as "holding," i think that gives a better mental image)== to each new peer they encounter. Until they only have one left. When a peer only has one copy left, they enter the wait phase for that message, waiting for a recipient to trigger delivery.

Stochastic spray and wait differs in that the number of copies of a message is randomly adjusted by a power of two by each recipient, and the relay never learns how the count was adjusted. This is done to help mitigate tracking attacks where a peer may be given exactly one copy of a message by an attacker, who will can use that peer's knowledge of the message to track their announce packets.

In Blizzard, "waiting" has an active component to help ensure recipient privacy. A node offers delivery of a message that it has run out of copies of by emitting an announce packet. An announce in Blizzard takes the form of a binary fuse filter containing a set of addresses the announcer has messages addressed to. The recipients of an announce will perform a lookup into the filter for each address in its active channels, and may attempt to trigger delivery if it finds matches for itself==(?)==.

If an adversary can determine the exact set of messages that a target has copies of, they may monitor the network looking for announce packets containing exactly those messages. This is impossible to completely mitigate without giving up recipient anonymity protections, but the choice of a probabalistic data structure helps here because enumerating the set is very difficult and results in about 2^48 possible entries, the fast vast majority of which are false positives.

Blizzard also has one more trick up its sleeve~~,~~. and that's the fact that before Before inserting an address into the filter, an announcer will repeatedly hash it a random number of times (up to 64), then truncate it. Enumerating the set only gives you these truncated address hashes. Since the hash is truncated, you don't an attacker does not have enough information to continue the repeated hashing forwards to correlate to other announce packets, and assuming the hash is not reversible you can't can not go backwards to recover the original address or its previous hashes. For the recipient of a message, it's relatively simple to repeatedly hash each address 64 times, performing a lookup each time to check for the address's presence. This mechansim limits attackers to only tracking addresses they know about (and can perform forward lookups of).

Usage

Blizzard is not ready for general use. The API and wire format should not be considered stable. It has not been simulated. It has not been audited.

Licensing

Blizzard is dual-licensed under Apache 2.0 and MIT.