Re: [manet] AODVv2: Security considerations update

I would say that in the interests of transparency, a lot more should appear on list. Of course there’s no need - until later stages - to discuss every editorial nit on list, but basic decisions should have been discussed here before now, and responses to comments received (I’ve never had responses to all my comments).

On this posting, it’s not exactly true that

   Encryption will not only make it more difficult for unauthorized devices to obtain
   information about network topology but will also ensure that only trusted
   routers participate in routing operations:

What ensure the latter is not encryption, but authentication. It is true that one should generally not use encryption without authentication, and there are some algorithms that do both together. Nevertheless I think it’s both useful and important to assign the right properties to each.

There’s then the practical issue that with a shared secret key, encryption and authentication are both (relatively) easy. But if you want a solution that isn’t that (because that has various drawbacks) then authentication is more manageable than encryption. For example draft-ietf-manet-ibs has a scheme (not of course the only possible one) for authentication. The equivalent for encryption that actually conceals network topology is hard (just revealing all addresses gives away quite a lot).

(Following the path of a signalling message is probably easier in a reactive network, because of the direct reaction.)

--
Christopher Dearlove
Senior Principal Engineer
BAE Systems Applied Intelligence Laboratories
__________________________________________________________________________

T:  +44 (0)1245 242194  |  E: chris.dearlove@baesystems.com<mailto:chris.dearlove@baesystems.com>

BAE Systems Applied Intelligence, Chelmsford Technology Park, Great Baddow, Chelmsford, Essex CM2 8HN.
www.baesystems.com/ai<http://www.baesystems.com/ai>
BAE Systems Applied Intelligence Limited
Registered in England & Wales No: 01337451
Registered Office: Surrey Research Park, Guildford, Surrey, GU2 7YP

From: manet [mailto:manet-bounces@ietf.org] On Behalf Of Lotte Steenbrink
Sent: 19 February 2016 15:06
To: manet@ietf.org
Subject: [manet] AODVv2: Security considerations update

----------------------! WARNING ! ----------------------
This message originates from outside our organisation,
either from an external partner or from the internet.
Consider carefully whether you should click on any
links, open any attachments or reply.
Follow the 'Report Suspicious Emails' link on IT matters
for instructions on reporting suspicious email messages.
--------------------------------------------------------

*** WARNING ***
EXTERNAL EMAIL -- This message originates from outside our organization.

Hi all,
in the interest of transparency, we (the AODVv2 author team) want to send out more updates on what we've been doing, and this is the first of these e-mails. We've restructured (and sometimes rewritten) our security considerations a bit and added a subsection about the Trust Model, and we'd love to hear your opinions on those changes. You can find the result and a diff to the current considerations in the attachments. (the formatting was done manually, so it might be a bit wonky)

Some notes:
* This is all work in progress, so please poke holes into it where you can!
* While (afaik) the Availability/Confidentiality/Integrity model may be considered a bit dated, I thought it might be a good starting point.
* I was wondering if “Encryption will not only protect against unauthorized devices obtaining
   information about network topology” isn't a tad too short and bold– maybe we could add a clarification along the lines of:

   Encryption will not only make it more difficult for unauthorized devices to obtain
   information about network topology but will also ensure that only trusted
   routers participate in routing operations: When messages are encrypted,
   a malicious observer would have to monitor the entire network to understand
   its topology and traffic flow. And even then, due to the hop by hop
   nature of the protocol and the fact that messages are regenerated rather
   than forwarded (resulting in a different payload every time),
   following the path of a message would be hard if its transmission is not
   the only encrypted traffic produced by the network.

Regards,
Lotte
_______________________________________________
manet mailing list
manet@ietf.org<mailto:manet@ietf.org>
https://www.ietf.org/mailman/listinfo/manet
********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************