Subject: Re: [manet] AODVv2: Security considerations update

From: Lotte Steenbrink <[email-masked]>
Date: Wed, 2 Mar 2016 16:41:55 +0100

Hi Ulrich and MANET members,
[for some reason my e-mail Client ate Ulrich's e-mail so I've copy & pasted it, I hope that doesn't mess up the thread/formatting too much]

Thanks for your quick and thorough response!
The reason I'm getting back to you just now is that we're currently incorporating your comments into the document and I wanted to answer with at least some work in progress. Attached you'll find what we've changed so far (and a diff from the last version). There are still a lot of TODOs in there, but this is the direction we're currently going in and the changes we've made.  (The quotes you'll find after some TODOs are from BCP72)

One additional thing that's not in the document yet but maybe should be addresses is an additional scenario for 13.1.3 False Confirmation of Link Bidirectionality:
A malicious node could also immediately answer a RREQ with a RREP that has stellar metric values, causing the genuine RREP of the route that is actually established to be discarded. 

Direct responses inline:

Ulrich Herberg <[email-masked]> Sat, 20 February 2016 16:41 UTC
> 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've read that it can be a non-exhaustive classification and I had the suspicion that there are many more axes to cover. 

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

Indeed. I hope we've resolved this with this update.

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

Just for the record, we didn't resolve this with the current version.

> 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 way I'm understanding the E-Mail you're citing, your issue with the word "regeneration" there is that overall regeneration is a more drastic measure than mere modification, and that this extra effort is unnecessary. That makes sense to me, but simple forwarding (and thus end-to-end protection?) of entirely unmodified messages won't be possible with AODVv2, since TLVs like Metric and ValidityTime and AckReq need to be updated hop by hop. Are you suggesting to add the option to exclude these TLVs during ICV calculation? I guess that would open the door to different attacks, but we could name "both sides" and let the implementers decide which is better for them? Or what am I misunderstanding here?
I guess the entire topic deserves its own thread...

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

Good point. We've restructured that section and tried to bullet-point-ify the overall document a bit more. What do you think?

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

We've converted shoulds to SHOULDs now and the section doesn't contain MAYs or mays...

> 
> - 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?

Afaik not; has ben added as a TODO.

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

Written down in the current version, but could be more detailed and step-by-step based.

> Best regards
> Ulrich

Kind regards,
Lotte