[Commotion-dev] SPAN Android App

[Jeremy Lakeman]

On Wed, Oct 17, 2012 at 4:51 AM, Robble, Jeff <jrobble at mitre.org> wrote:
> The packet layout helps clarify. 256-bit key addresses are used to
> determine how to route packets between serval daemons in user space. IP
> addresses are still used to send packets between devices over the wireless
> interface.
>
> I assume the "payload body" is the only part of each serval payload that's
> encrypted and it's encrypted using only the final destination's public
> key. Is that accurate?

Correct.

> You mention that the source IP address is used to only send a unicast
> reply. I assume that a message with payloads destined for specific peers
> (i.e. the message does not contain a broadcast) is sent via unicast to the
> next hop. Is that accurate or are all messages broadcast over the wireless
> interface, received by the serval daemon on each device, and filtered
> accordingly?

We prefer to send broadcast packets so we can include payloads for
multiple neighbours in the same frame, and it more closely matches
what's happening at the physical layer. We will need to fall back to
unicast packets if our neighbour can't hear our own broadcast packets.
Many android devices filter broadcasts when entering a low power
state, and some filter broadcasts all the time.

Though broadcast packets are more unreliable on ad-hoc wifi, if
there's a collision or interference the packet will be lost. While the
wifi layer will ack / nack unciast packets and will retry a few times
until successful, we've found a couple of devices like Samsung G SII
that retry so much in burst mode they consume all available bandwidth
for ~0.9 seconds.

Since we're expecting to route packets over a mesh, if a transmission
fails it may indicate that the topology has changed and any retry may
need to take a different path. Though we haven't implemented retries
at the network level yet.

> I'm trying to figure out if your version of OLSR is using IP addresses or
> 256-bit key addresses. Does serval perform a lookup on the next hop
> 256-bit key addresses to determine its IP address and then send the
> message via unicast to that IP address?

If we're running in our new experimental olsr mode, we don't actively
try to determine the topology of the mesh at all, that's olsr's job.
We use a similar payload header for messages we send via olsr's
flooding service, and we establish a routing table entry mapping PK to
IPv4 address. Then we always send unicast IP packets directly to the
final destination. This has a lot in common with our approach for
routing payloads via the internet.

Since we can run a network in either mode, we should be able to easily
compare our routing engine to olsr to compare performance. I'm not
expecting us to beat olsr yet, we've still got a lot of work to do.
But if we get close, we should be able to prove it.

While serval does support devices with multiple interfaces, we haven't
tackled use cases where those interfaces use different modes of
routing. Either all devices should be in olsr mode, or all devices
should be routing via our protocol.

> Jeffrey Robble
> Software Systems Engineer
> The MITRE Corporation (Bedford)
> Office: 781.271.2790
>
>
>
>
> On 10/15/12 8:20 PM, "Jeremy Lakeman" <Jeremy.Lakeman at gmail.com> wrote:
>
>>On Tue, Oct 16, 2012 at 9:04 AM, Robble, Jeff <jrobble at mitre.org> wrote:
>>> Thanks for the clarification Jeremy.
>>>
>>> So you're randomly generating a 256-bit key pair and using the public
>>>key
>>> as the device network address. When you want to send data the serval
>>> daemon encrypts it using the 256-bit IP address of the destination and
>>> encapsulates it in a IP/UDP packet. Am I misunderstanding?
>>
>>A picture is worth a thousand words... The logical structure of our
>>transmitted IP packets look something like this;
>>
>>[ethernet header; source MAC, dest MAC, ...]
>>[ip / udp header; source IP, dest IP, source port, dest port, ...]
>>[serval packet format version number]
>>[transmitting device PK]
>>[payload list;
>>  [payload;
>>    - original source PK
>>    - final destination PK or broadcast identifier for de-duplication
>>    - next hop PK
>>    - payload length
>>    - payload body
>>  ],
>>  ...
>>]
>>
>>Though the wire format does have some space saving tricks for sending
>>short abbreviations for PK addresses that are already known by both
>>parties.
>>
>>When we receive a packet, we only use the source IP address to work
>>out where to send unicast reply packets destined for the "transmitting
>>device PK". And only if we're running in olsr mode or the transmitter
>>is in a different network sub-net.
>>
>>We then look through the payload list for anything addressed to us as
>>the destination or next hop address, and process and/or forward them.
>>
>>So yes, the network discovers public keys as it builds the routing
>>table and communicates with other devices. So we can easily encrypt
>>any packet with a PK destination over the network. But that doesn't
>>mean we've authenticated anyone's identity or done anything to detect
>>a man-in-the-middle attack.
>>
>>Public key verification is still best done in person. Though we are
>>also looking at verification via an audio channel; relying on your
>>brain's ability to do voice print verification of identity, while
>>confirming the fingerprint of a shared secret.
>>
>>Eventually we may also implement key signing for building a web of trust.
>