Proxy Payload Delivery

From Entuura

If we had a device in the field with no access to GSM (not to mention satellite, DSL, etc), but we had a regular way to visit it physically, can we still send payloads to it (and get payloads from it)?

Of course. This is just Sneaker Net, and the First Mile Solutions guys have done it for a long time with wifi boxes on motorcycles.

In our architecture the way you do it is for the disconnected node to issue an authorization to the central server nominating one or more of the connected nodes to act as a proxy for it. In response to this authorization (which arrives as a signed payload of type .control, an imaginary network-control payload format that I made up just now...) the central server makes a symlink in the pobox directory of the delegate pointing to the node that authorized access.

For example, say BeyondKwale sends in a control message saying, "Please allow Kwale to pick up payloads for me". Then the central server honors that request by making this link:

• data/pobox/BeyondKwale.Kenya-Health.entuura.org
  • from-device
  • to-device
• data/pobox/Kwale.Kenya-Health.entuura.org
  • from-device
  • to-device
  • BeyondKwale.Kenya-Health.entuura.org -> ../BeyondKwale.Kenya-Health.entuura.org

(Because we use the FQDN here, it's possible that cross-community rely is possible, though we need to think out the security and encryption parts of this to be sure it should be allowed.)

At the same time, the device sends a .control message to the delegate saying, "from now on, when you phone home for yourself, you should also pick up stuff for me". Of course, it is at the discretion of the new delegate whether to accept or decline this responsibility. If it declines it, it could do so silently and just force the disconnected guy to get his payloads some other way. In fact, there's no reason (modulo locking issues) that the disconnected device cannot deputize several connected nodes, and any of them can take responsibility for the payloads. (But our payload delivery is best-effort, so if delegate D2 takes responsibility for the payloads, but never has a chance to talk to node N, D1 will never have a chance to try to get them to node N, even if D1 and N are talking daily.)

The final bit is how to do the sneaker net part of the transaction, when payloads are moved from the device. It seems like our USB sticks should have a file that says, "I belong to $X" in it, so that when the stick is put into a different device, the device says, "Oh, I see that you belong to $X, and I have payloads waiting for you, here you go." The manufacturer's serial number is available from Linux easily, that might be the best way to identify the USB stick. Here's an example:

jra@nano:/proc/scsi/usb-storage$ cat 3 
   Host scsi3: usb-storage
       Vendor: LG
      Product: USB Drive
Serial Number: AA04012700008322
     Protocol: Transparent SCSI
    Transport: Bulk
       Quirks:

Of course, there is the chicken and egg problem that a node that is not on the network cannot send the initial "delegate authorize" message. But we've already postulated that configuration will always happen in a lab with broadband access (i.e. in the country manager's office in the capital city) so it's OK to assume the chicken/egg problem is solvable.

So, the key concepts:

• Leverage the PKI to allow the devices to name their delegates securely -- makes network topology management ground-up, instead of burdening the central server with it.
• The central server maintains symlinks to represent the delegations, but otherwise is uninterested in the details.
• Devices take responsibility for implementing the system in a distributed manner

Implementing the Village Moto-Man system

Once you have the above implemented, it is not a very far jump to a mobile node, a la First Mile Solutions. All fixed, disconnected nodes delegate their payload delivery to the mobile node. The mobile node runs a daemon that knows how to CIFS mount the TS directory when it detects an Entuura-$NODE wifi signal. It transfers the payloads and umounts the directory. Perhaps we could build a hook into samba to run a script on umount. Perhaps such a hook already exists.

Question: what do do for security? Not really very hard... we already have a PKI, there has got to be a way to leverage that so that the mobile node can authenticate itself to the fixed node.

But read on for a better idea...

Who is the server? Who runs the daemon?

Or perhaps it should work the other way... devices which have delegated authority to node $NODE should always be running a daemon looking for a wifi network of "Entuura-$NODE". If they see it, they connect. Perhaps the "delegate" control message originally had a piece of random data which is used as the password for the Samba server on the mobile device. Once the fixed node mounts it's own payload directory, it copies them over to it's USB stick just like a normal phone-home. It should enqueue a .control message indicating it received a visit from the mobile device on this time and date. (This is the offline version of the Phone Home hello step.)

The mobile device never processes the payloads (i.e. runs ts-process-dir), so it doesn't care about them coming and going. It just allows the nodes to read and write their payloads. The mobile device is trying to phone home on a regular basis, and when it succeeds (becuase it's WAN port is plugged into an ethernet (with POE!) at the office during it's nightly charge), then it sends not only it's own payloads, but all those it collected during the day. And of course, it receives payloads for all the nodes that have delegated payload transport to it.

Shared Uplink? (But only for Payloads, not for full IP acccess)

Would there ever be a situation where there are two devices within wifi range, one has an uplink to the net, and the other no? In that case, if you didn't want to maintain a unified network with complete access (i.e. the device with no uplink has a default route to the one with an uplink), the device with no uplink could delegate to the one with an uplink. Then the two devices can have an arm's length relationship with respect to IP, but payloads can still flow.

This is a use case related to the disaster relief context, where there might be a satellite connection that can be shared -- but only for Entuura payloads, not for full IP access.