As the Serval Project is based in a University, we have a need to write academic papers. However, such papers take a while to write, get peer reviewed and published. This is a problem since Serval is also an open-source project, and we need to get information out to the community in a timely manner.
So I am trying an experiment. I am progressively moving all paper preparation activity into our github repository (http://github.com/servalproject/serval-docs/).
Some legacy documents will be in LibreOffice /OpenOffice format.
For new documents I will be aiming to use LyX (a LaTeX frontend), because commits that change documents will result in meaningful diffs between versions. Also figures exist as separate files, and so are easier for people to access, update and/or reuse.
One of the nice advantages is that people can submit corrections, view older revisions, or submit "bugs" or "feature enhancements" for improvements to the document. Overall, it seems like it should result in better papers.
Anyway, the first document there is a document describing Serval Rhizome.
Thursday, October 25, 2012
Monday, October 15, 2012
Secure Communications Is Valuable
Well, we already knew this, but it is pleasing to see when others create things that are similar to what we are doing. In this case, it is Phil Zimmermann (of PGP fame). He has a startup called Secure Circle offering secure telephony and messaging:
http://www.fastcompany.com/3001938/phil-zimmermanns-silent-circle-builds-secure-seductive-fortress-around-your-smartphone
The actual company website is here.
Similarities between Silent Circle and Serval include the use of ECC for the crypto (we are using Curve25519 (effectively 251 bits) while they are using the NIST 384-bit curve), and some of the telephony services being offered. There is no reason why we couldn't move to 384-bit or stronger crypto, but we do not see the need at this time. It would be quite possible for us (or someone else) to switch out the crypto system for a different one should people desire to do so. The most practical reason why we are are not yet on a longer ECC system is that the NaCl library that we use is yet to support one, which reflects, in part, the fact that a (well implemented) 251-bit ECC system offers ample security for the time being.
Differences include that Serval is free (as in beer and as in liberty) and open-source, and rather importantly, that Serval technologies are designed for resilience, and do not require a cellular network or internet access to facilitate communications.
http://www.fastcompany.com/3001938/phil-zimmermanns-silent-circle-builds-secure-seductive-fortress-around-your-smartphone
The actual company website is here.
Similarities between Silent Circle and Serval include the use of ECC for the crypto (we are using Curve25519 (effectively 251 bits) while they are using the NIST 384-bit curve), and some of the telephony services being offered. There is no reason why we couldn't move to 384-bit or stronger crypto, but we do not see the need at this time. It would be quite possible for us (or someone else) to switch out the crypto system for a different one should people desire to do so. The most practical reason why we are are not yet on a longer ECC system is that the NaCl library that we use is yet to support one, which reflects, in part, the fact that a (well implemented) 251-bit ECC system offers ample security for the time being.
Differences include that Serval is free (as in beer and as in liberty) and open-source, and rather importantly, that Serval technologies are designed for resilience, and do not require a cellular network or internet access to facilitate communications.
Monday, October 8, 2012
Using Serval as a Basis for Environmental Monitoring
One of our developers, Corey Wallis, is in the midst of a project with some of the other researchers in the Flinders University Disaster Research Centre (DRC) where they are creating a system to acquire temperature and humidity data from mass gathering events, such as concerts and sports events.
This involves both fixed and mobile devices with sensors continuously collecting data for analysis both at the event and on-line.
One of the tricks is that we can't rely on cellular service being available at these events. Also, we want all of the field teams who are gathering data to also be able to visualise and act on the data, so we need a many-to-many distribution scheme.
These features make it an good fit for Serval Rhizome, our store-and-forward/Delay Tolerant Networking (DTN) system, that is able to handle both of these requirements, and will result in a very versatile system that can be used anywhere in the world.
Corey has made some good progress on the hardware and software for the data gathering, as can be seen in this blog post:
http://magdaaproject.org/2012/10/08/mobile-environment-monitoring-software-update/
Among the next steps are to actually integrate it with the Serval Mesh software so that the data can be shared among the field teams and analysis staff.
This involves both fixed and mobile devices with sensors continuously collecting data for analysis both at the event and on-line.
One of the tricks is that we can't rely on cellular service being available at these events. Also, we want all of the field teams who are gathering data to also be able to visualise and act on the data, so we need a many-to-many distribution scheme.
These features make it an good fit for Serval Rhizome, our store-and-forward/Delay Tolerant Networking (DTN) system, that is able to handle both of these requirements, and will result in a very versatile system that can be used anywhere in the world.
Corey has made some good progress on the hardware and software for the data gathering, as can be seen in this blog post:
http://magdaaproject.org/2012/10/08/mobile-environment-monitoring-software-update/
Among the next steps are to actually integrate it with the Serval Mesh software so that the data can be shared among the field teams and analysis staff.
Saturday, October 6, 2012
The Serval Technology Stack
Back when we started with the Serval Project we were focussed on creating a proof-of-concept that showed the potential of the concept of enabling mobile telephones to communicate directly, and allow people to communicate in difficult situations.
As a result of that approach, we took largely existing VoIP and mesh routing technologies and fitting them into a mobile telephone.
We already had ideas at the time that there was a better approach. This was reinforced by our early experience where we found that the combination of SIP was very sensitive to packet loss during call setup.
To cut a long story short, we decided to implement our own suite of mobile mesh oriented protocols overlay network, and mesh oriented protocols and technologies to replicate the core functionality, not just of SIP/VoIP, but also UDP-style datagram services, file distribution, SMS-like services and more.
Today I presented at #IS4CWN describing this new technology stack and explained a lot of our reasoning behind it. I have been meaning to document some of this for a while, and now it has finally happened. Now that I have some diagrams and slides, my intention is to write a series of posts explaining the various parts of the new Serval technology stack.
For this post I want to start with an overview of the new technology stack, which I will then expand on each part in future posts.
Starting at the bottom, we have the various base layers that the Serval Mesh protocols all might be encapsulated in. While the current implementation is an overlay encapsulated in IPv4 UDP packets, the overlay was designed to allow the kind of flexibility reflected here, with digital packet radio and other transports being anticipated from the outset.
The trained squirrels is somewhat tongue-in-cheek, but serves to represent that we are thinking broadly about the form of possible transports. It is hard to write kernel drivers that can expose a fleet of trained squirrels as a first-class network interface on a variety of operating systems, and the same goes for packet radio and other interfaces.
This is a good reason for us to pursue an overlay network approach, because it avoids the need for kernel cooperation, even if using strange transports. It also allows us to step back from some of the overheads and anachronisms of IP networking that are not appropriate for low-bandwidth or high-latency links, such as packet radio.
This naturally leads into explaining the nature of the Serval Overlay Mesh protocols itself. As mentioned, one reason for pursuing the an overlay model is to allow the use of non-conventional packet transports. Another reason is to avoid the pain of IP address allocations. IPv4 doesn't have enough address space to allow random self-allocation of addresses at a global scale. It also turns out that IPv6 doesn't either, because there are only 64 host address bits, and there are more than 2^(64/2) people and devices in the world, which is the practical limit for random address allocation. Structured address allocation is not feasible for mobile mesh networks that are intended to provide resilient communications. Further, not all mobile phone platforms support IPv6.
So our view is that IPv6 doesn't really offer any compelling advantage for our use-case. Our approach was to instead use 256-bit Elliptic Curve Cryptography public keys as network addresses. This also makes end-to-end encryption of communications between nodes trivial, because a Diffie-Hellman shared secret agreement process can be used to facilitate the use of a stream cipher. And this is exactly what we have implemented for our Mesh Datagram Protocol (MDP), which is otherwise very much like UDP.
The transparent encryption offered by MDP is used to host our Voice over Mesh Protocol, which then benefits from this. Of course security isn't just encryption, and there are authentication and man-in-the-middle attack issues to be considered. But I will leave that discussion for a future post.
So that covers the right hand side of our protocol stack, which is all the real-time protocols.
The left hand side covers the Rhizome store-and-forward or Delay Tolerant Networking (DTN) protocol and applications layered on top of that. Full explanation of that will also be the subject of a future post.
As a result of that approach, we took largely existing VoIP and mesh routing technologies and fitting them into a mobile telephone.
We already had ideas at the time that there was a better approach. This was reinforced by our early experience where we found that the combination of SIP was very sensitive to packet loss during call setup.
To cut a long story short, we decided to implement our own suite of mobile mesh oriented protocols overlay network, and mesh oriented protocols and technologies to replicate the core functionality, not just of SIP/VoIP, but also UDP-style datagram services, file distribution, SMS-like services and more.
Today I presented at #IS4CWN describing this new technology stack and explained a lot of our reasoning behind it. I have been meaning to document some of this for a while, and now it has finally happened. Now that I have some diagrams and slides, my intention is to write a series of posts explaining the various parts of the new Serval technology stack.
For this post I want to start with an overview of the new technology stack, which I will then expand on each part in future posts.
Starting at the bottom, we have the various base layers that the Serval Mesh protocols all might be encapsulated in. While the current implementation is an overlay encapsulated in IPv4 UDP packets, the overlay was designed to allow the kind of flexibility reflected here, with digital packet radio and other transports being anticipated from the outset.
The trained squirrels is somewhat tongue-in-cheek, but serves to represent that we are thinking broadly about the form of possible transports. It is hard to write kernel drivers that can expose a fleet of trained squirrels as a first-class network interface on a variety of operating systems, and the same goes for packet radio and other interfaces.
This is a good reason for us to pursue an overlay network approach, because it avoids the need for kernel cooperation, even if using strange transports. It also allows us to step back from some of the overheads and anachronisms of IP networking that are not appropriate for low-bandwidth or high-latency links, such as packet radio.
This naturally leads into explaining the nature of the Serval Overlay Mesh protocols itself. As mentioned, one reason for pursuing the an overlay model is to allow the use of non-conventional packet transports. Another reason is to avoid the pain of IP address allocations. IPv4 doesn't have enough address space to allow random self-allocation of addresses at a global scale. It also turns out that IPv6 doesn't either, because there are only 64 host address bits, and there are more than 2^(64/2) people and devices in the world, which is the practical limit for random address allocation. Structured address allocation is not feasible for mobile mesh networks that are intended to provide resilient communications. Further, not all mobile phone platforms support IPv6.
So our view is that IPv6 doesn't really offer any compelling advantage for our use-case. Our approach was to instead use 256-bit Elliptic Curve Cryptography public keys as network addresses. This also makes end-to-end encryption of communications between nodes trivial, because a Diffie-Hellman shared secret agreement process can be used to facilitate the use of a stream cipher. And this is exactly what we have implemented for our Mesh Datagram Protocol (MDP), which is otherwise very much like UDP.
The transparent encryption offered by MDP is used to host our Voice over Mesh Protocol, which then benefits from this. Of course security isn't just encryption, and there are authentication and man-in-the-middle attack issues to be considered. But I will leave that discussion for a future post.
So that covers the right hand side of our protocol stack, which is all the real-time protocols.
The left hand side covers the Rhizome store-and-forward or Delay Tolerant Networking (DTN) protocol and applications layered on top of that. Full explanation of that will also be the subject of a future post.
Subscribe to:
Posts (Atom)