Subject: [manet] Stephen Farrell's Discuss on draft-ietf-manet-olsrv2-sec-threats-03: (with DISCUSS)

From: "Stephen Farrell" <[email-masked]>
Date: Thu, 05 Jan 2017 05:27:51 -0800

Stephen Farrell has entered the following ballot position for
draft-ietf-manet-olsrv2-sec-threats-03: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

I have two things I'd like to discuss to see if
changes are needed or not:

(1) Neither this nor RFC7186 seem to consider battery
depletion attacks. Why is that ok?

(2) 6.2: HMAC is *not* a digital signature mechanism.
While loose terminology may be ok elsewhere, in this
case, you shouldn't do that as it can lead to wrong
conclusions. Digital signatures do provide origin
authentication of sorts, but MACs do not, especially
if keys are shared. It is not clear to me that some of
the claims in 6.2.x of attacks being mitigated are in
fact correct, given shared secrets. (Note: It could be
that the claims are correct, I didn't have time to
check back on all the vulnerability definitions,
sorry. But I'd like to check, given the defective
terminology.)

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Thu, 5 Jan 2017 14:21:18 +0000

Not an author, but I hope this is useful. It follows up Stephen's second point.

RFC 7182 describes a mechanism for adding ICVs to anything based on RFC 5444 format (which includes OLSRv2). It includes code points for some ICVs that may be signatures and some that aren't - I think more of the latter.

RFC 7183 is, roughly speaking, an RFC 7182 option for OLSRv2 (and NHDP) implementation. It's called out from RFC 7181 (OLSRv2) as a "must implement, don't need to use" mechanism. It specifies the HMAC/SHA-256 option indicated. It is shared secret key, and thus isn't a signature (as Stephen notes).

Reading Section 6.2 with that in mind, apart from the use of signature, I think mostly it's OK, the RFC 7183 option will work as described if nothing is compromised, but I'm not sure about the final parenthesised piece at the end of the first long paragraph. If you want to be able to revoke you want to be using a different RFC 7182 (or extension) option, as noted an asymmetric one, not the RFC 7183 option, and I don't think that's clear. Possibly "in addition" is meant to mean something more like "alternatively" (though it is not a simple text change like that) but should reference RFC 7182.

(I think the ICVs that might be signatures in RFC 7182 are probably underspecified, which goes back to RFC 6622 of which it is an update. There is an ICV that is a signature in RFC 7859, an extension to RFC 7182, but that is experimental, although specified in some detail.)

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

T:  +44 (0)1245 242194  |  E: [email-masked]

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

-----Original Message-----
From: manet [mailto:[email-masked]] On Behalf Of Stephen Farrell
Sent: 05 January 2017 13:28
To: The IESG
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: [manet] Stephen Farrell's Discuss on draft-ietf-manet-olsrv2-sec-threats-03: (with DISCUSS)

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

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

I have two things I'd like to discuss to see if changes are needed or not:

(1) Neither this nor RFC7186 seem to consider battery depletion attacks. Why is that ok?

(2) 6.2: HMAC is *not* a digital signature mechanism.
While loose terminology may be ok elsewhere, in this case, you shouldn't do that as it can lead to wrong conclusions. Digital signatures do provide origin authentication of sorts, but MACs do not, especially if keys are shared. It is not clear to me that some of the claims in 6.2.x of attacks being mitigated are in fact correct, given shared secrets. (Note: It could be that the claims are correct, I didn't have time to check back on all the vulnerability definitions, sorry. But I'd like to check, given the defective
terminology.)

_______________________________________________
manet mailing list
[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: Jiazi Yi <[email-masked]>
Date: Thu, 12 Jan 2017 00:25:49 +0100

Hi, 

Thanks very much for the comments and the reply from Chris. 

> On 5 Jan 2017, at 14:27, Stephen Farrell <[email-masked]> wrote:
> 

The battery depletion is a kind of attacks by consuming extra resources. In RFC7186, we mentioned:

   In some MANETs, the routers are powered by battery.  Another
   consequence of a DoS attack in such networks is that the power will
   be drained quickly by unnecessary processing, transmitting, and
   receiving of messages.

And it’s true that we didn’t call it out in the current draft. We made it more explicit in the new revision:

   In a different
   class of attacks, a compromised OLSRv2 router injects control
   traffic, designed so as to cause an in-router resource exhaustion,
   e.g., by causing the algorithms calculating routing tables or MPR
   sets to be invoked continuously, preventing the internal state of a
   router from converging, depleting the energy of battery-driven
   routers, etc.

> sorry. But I'd like to check, given the defective

We updated the term used and the phrase that Chris mentioned. 

thanks very much!

regards

Jiazi