Subject: [manet] AODVv2: Security considerations update

From: Lotte Steenbrink <[email-masked]>
Date: Fri, 19 Feb 2016 16:05:54 +0100

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

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Fri, 19 Feb 2016 15:52:09 +0000

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: [email-masked]<mailto:[email-masked]>

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:[email-masked]] On Behalf Of Lotte Steenbrink
Sent: 19 February 2016 15:06
To: [email-masked]
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,

Some notes:

Regards,
Lotte
_______________________________________________
manet mailing list
[email-masked]<mailto:[email-masked]>
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.
********************************************************************

---

From: Ulrich Herberg <[email-masked]>
Date: Sat, 20 Feb 2016 08:41:18 -0800

Hi Lotte,

I agree with what Chris said.

Can you clarify what you mean in your email by:
"[...] (afaik) the Availability/Confidentiality/Integrity model may be
considered a bit dated [...]"?

I have a few concerns with the proposed security considerations section:

- BCP72 specifies:
===================
"Authors MUST describe

      1.   which attacks are out of scope (and why!)
      2.   which attacks are in-scope
      2.1  and the protocol is susceptible to
      2.2  and the protocol protects against

   At least the following forms of attack MUST be considered:
   eavesdropping, replay, message insertion, deletion, modification, and
   man-in-the-middle.  Potential denial of service attacks MUST be
   identified as well.  If the protocol incorporates cryptographic
   protection mechanisms, it should be clearly indicated which portions
   of the data are protected and what the protections are (i.e.,
   integrity only, confidentiality, and/or endpoint authentication,
   etc.).  Some indication should also be given to what sorts of attacks
   the cryptographic protection is susceptible.  Data which should be
   held secret (keying material, random seeds, etc.) should be clearly
   labeled.
"
===================

I don't think all of the above MUSTs are addressed in the proposed
text (see also below).

- I think the chain-of-trust model that doesn't allow end-to-end
integrity protection is problematic in an entirely distributed and
untrusted network environment. It's a bit like saying that you trust
that an email sent to someone else is integrity protected because the
step-wise SMTP between various mail servers along the path uses TLS.
This brings me to the deeper issue of why messages are regenerated
instead of forwarded. I have not understood why this is necessary in
the first place (and I argued this in an email to the list at
https://www.ietf.org/mail-archive/web/manet/current/msg18081.html)

- The text in section 13.3.1  is hard to interpret as implementer,
since it mixes a security evaluation with the actual specifications of
how to protect the messages. I think it would be better to have
separate sections for these two parts. Also, as a stylistic
recommendation, I always had a hard time reading the continuous text
as opposed to bullet points as we applied in OLSRv2.

- I have some doubts that the Security ADs will agree with the terms
"recommendations" in the title of the section together with a lot of
SHOULDs and MAYs in the text, which seems to imply that usage of the
integrity protection is not mandatory. When specifying OLSRv2, we were
clearly told that we require a "MUST-implement/SHOULD use until you
have something more better".

- The Sec ADs required us for OLSRv2 to argue (in the spec) why we
don't need to specify automatic key management as per BCP107. I don't
see a similar section in AODVv2. Have you confirmed with the Sec ADs
that their requirements have been relaxed?

- The biggest issue I have with the proposed security consideration
text is that there is no detailed specification of how to sign and
validate messages, similar to what we were required to do by the Sec
ADs in RFC7183. I doubt that two AODVv2 implementations by different
programmers would be interoperable just using the current text. You
mention the functions specified in RFC7182; but really these are just
the containers for the actual information. RFC7182 does not mandate
how to use them (such as we do in RFC7183).

Best regards
Ulrich

On Fri, Feb 19, 2016 at 7:52 AM, Dearlove, Christopher (UK)
<[email-masked]> wrote:
> 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).
>
>
>
> 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
> T:  +44 (0)1245 242194  |  E: [email-masked]
>
> www.baesystems.com/ai
> 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:
> * While (afaik) the Availability/Confidentiality/Integrity model may be
> considered a bit dated, I thought it might be a good starting point.
>    information about network topology” isn't a tad too short and bold– maybe
> we could add a clarification along the lines of:
>
> [email-masked]
> [email-masked]

---

From: Abdussalam Baryun <[email-masked]>
Date: Sat, 20 Feb 2016 21:12:25 +0200

On Fri, Feb 19, 2016 at 5:52 PM, Dearlove, Christopher (UK) <
[email-masked]> wrote:

> 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).
>

I agree. We need to get all comments together and responded to. For me it
is easier to make feedback on list if the chair is active but if not,
then I suggest we use the ticket-tracker to make it easy to the authors to
track the issues. I see the tickets about 20 (I think some were submitted
for chris and other participants).

http://trac.tools.ietf.org/wg/manet/trac/query?status=!closed&component=aodvv2

---

From: Jiazi YI <[email-masked]>
Date: Sun, 21 Feb 2016 22:37:33 +0100

Hi,

Regarding the trust model:

13.4 Trust Model
>    Since routing information is distributed to neighbours on a hop-by-hop
> basis,
>    and route messages are regenerated at each router, AODVv2 assumes a
> security
>    model of transitive trust.

"information distributed on hop-by-hop basis" applies to almost all
multi-hop networks.

"route messages are regenerated at each router" is questionable and has
been discussed in previous sessions. I couldn't remember that it was
accepted by the WG.

Especially, the reasons justifying this trust model seems to be more
because of the limitation of a protocol design, rather than the
requirements from real applications.

> The sender of a message must be trusted in order
>    for receiving one-hop neighbours to store the routing information it
>    provides and regenerate the message to their own one-hop neighbours.

   Routes are installed based on information received from trusted
> neighbours.
>    Therefore a chain of trust back to the originator of a message is
> assumed
>    by any router using the routing information received.

In ad hoc networks, it's hard to avoid having compromised routers,
especially in adverse environments (which is an important application
scenario of MANETs).

For AODV, the RREQ/RREP messages are designed to be end-to-end. Especially,
RREQ is to be disseminated to the whole networks. Using the transit trust
model means, if there is a single compromised router, the whole network is
compromised. Even worse, there is no way (like identity based signature)
can be used as countermeasures because of the limitation of the trust
model.

best

Jiazi

On Fri, Feb 19, 2016 at 4:05 PM, Lotte Steenbrink <
[email-masked]> wrote:

>    information about network topology” isn't a tad too short and bold–
> maybe we could add a clarification along the lines of:
>