Re: [secdir] Sector review of draft-ietf-manet-rfc6779bis-05

["Dearlove, Christopher (UK)" <[e-mail]>]

The MIB information can largely, though not quite entirely, be reconstructed from the routing signalling. And there’s no proposal on the table that encrypts that. (Future work, perhaps.)

Consequently mandating encryption of MIB data really doesn’t help much. In fact I think that although the MIB information may add a little, it isn’t regular, and only some of it might be requested, unlike the routing signalling that is continual and everywhere. So I’d classify it as secondary in value to an attacker.

That said, encrypting it is easier, because encrypting routing signalling either requires a shared secret key everywhere, which is weak, or runs into the chicken and egg problem of which comes first, establishing the routing - in particular the neighbour discovery - or establishing the encryption for that signalling. There are solutions, but as I said, none yet proposed. Whereas for MIB information routing is already in place, and hence can be used.

What does that mean? Speaking just for myself, I think that means that the current draft might have the balance in the right place. But I’ll leave that for others to discuss/decide.

(In fact even authenticating the routing signalling isn’t mandated; although implementing an approach  - a weak one, but there are better -  to it is. However anyone using this in a sensitive scenario would be ill-advised not to use an authentication mechanism, hence this just being an aside.)

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

T:  [phone]  |  E: [e-mail]<mailto:[e-mail]>

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: Vincent Roca [mailto:[e-mail]]
Sent: 24 May 2016 07:37
To: IESG; [e-mail]; [e-mail]
Cc: Vincent Roca
Subject: Sector review of draft-ietf-manet-rfc6779bis-05

Hello,

I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.


Summary: ready

The security considerations section is a carbon copy of that of RFC 6779 published in 2012. The only modification is the addition of a reference to "Mobile Ad Hoc Network (MANET)".

As explained by the authors, information contained in this MIB is highly sensitive, both from the security and privacy point of views. This is all the most true when considering some of the target use-cases (emergency services or military tactical applications).

If I find this section globally well written. I'm just a bit surprised by the following sentence:
            "It is thus important to control even GET and/or NOTIFY access to these objects
             and possibly to even encrypt the values of these objects when sending them
            over the network via SNMP."
I would rather say that it is essential to encrypt and verify the integrity of all the SNMP traffic. Here I find the style not sufficiently directive... But this is a detail.


Cheers,

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