Hello John,
I agree that every disclosure of information is potentially harmful, but
I also think the harm has to be balanced against the realistic danger.
More follow-up below...
On 3/1/2016 9:39 AM, John Dowdell wrote:
Hi all
Had a look through Charlie’s spreadsheet and have some comments as below.
1. Confidentiality. While the disclosure of routing signals might not be harmful to a node per se, it is harmful to a network as a whole, since it allows an attacker to determine which nodes are sending user traffic to which other nodes. Remember this is on-demand routing, so the presence of a route directly infers user traffic will traverse it. Thus it is even more useful to an attacker than the usual DV routing tables which just point to other nodes.
2. Offline cryptographic attacks. Low volume of traffic by itself does not protect from such attacks. If the messages are regular, highly structured and short, they are actually even more open to attack. The choice of message encryption or packet encryption becomes important here, since a packet could theoretically contain multiple messages and thus be longer, but in practice that might not be the case. For an open source example, watch “The Imitation Game” if you haven’t already done so. The breakthrough comes, according to the film, when they realise they don’t have to attempt to attack the whole message by brute force, trying every possible combination, just the first word and last two words which are always the same on a weather report message sent by a particular operator first thing in the morning.
3. What about potential attackers?
a. If all routers in a group have wireless links protected using the same cryptographic key, an attacker has to acquire the key or certificate. There are well known attacks for an 802.11 secured wireless connection, and doubtless others for other open standard interfaces. The usual security policy is to assume the attack will happen (I’m waiting for the first ransomware attack on an industrial freezer connected IOT-style) or even has already happened, and work out how to mitigate it by defence in depth. If inside the secured link we are using TLS to protect the management traffic, then we need reasonably accurate time of day and to securely store certificates that are regularly changed. Then we can do integrity checks and so forth.
b. Once the attacker is inside, what then? That’s when the anti-replay measures come into play, and as Charlie says we should also consider the message insertion/deletion/modification and denial of service attacks, particularly as this could be running on very small processors which could easily be overwhelmed by DoS. I’d want to verify the authenticity and integrity of incoming messages as early as possible and somehow defend against overload.
c. This is before you get to topics such as defending against link flap with wireless links that are on the edge of their coverage, which will happily bring a network down by overwhelming even dedicated big-iron network processors, if there is enough of it going on. I’ve seen it happen with PowerPC and VxWorks powered boxes, so a sloppy implementation on an ARM Cortex M-series processor could easily be overwhelmed.
4. Message Regeneration
As I think I have mentioned before, DTNwg have the exact same problem here, except theirs is a payload (aka bundle) protection problem not a network signalling one as such. Some bundles are end-to-end and some are hop by hop. Thus DTN need end to end security and hop by hop security. DTN isn’t there yet and has considerable distance to go in standards-track work. It may be helpful to look at the AODVv2 message parts that go end-to-end and secure those differently to how regenerated messages are secured. I realise I’m not being helpful by offering a complete solution, and I’m not even sure we should offer a fully-worked up solution ion the I-D, since manufacturers and system integrators need some wiggle room to suit their particular circumstances.
