Re: [secdir] Sector review of draft-ietf-manet-rfc6779bis-05
"Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com> Tue, 24 May 2016 08:58 UTC
Return-Path: <chris.dearlove@baesystems.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 34BBB12D1EB; Tue, 24 May 2016 01:58:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.345
X-Spam-Level:
X-Spam-Status: No, score=-8.345 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-1.426] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HBbtPPvlT_ba; Tue, 24 May 2016 01:58:55 -0700 (PDT)
Received: from ukmta2.baesystems.com (ukmta2.baesystems.com [20.133.0.56]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52B0012D0EB; Tue, 24 May 2016 01:58:54 -0700 (PDT)
X-IronPort-AV: E=Sophos; i="5.26,359,1459810800"; d="scan'208,217"; a="35884443"
Received: from unknown (HELO baemasmds016.greenlnk.net) ([10.15.207.101]) by ukmta2.baesystems.com with ESMTP; 24 May 2016 09:58:45 +0100
X-IronPort-AV: E=Sophos;i="5.26,359,1459810800"; d="scan'208,217";a="119383083"
Received: from glkxh0005v.greenlnk.net ([10.109.2.36]) by baemasmds016.greenlnk.net with ESMTP; 24 May 2016 09:58:46 +0100
Received: from GLKXM0002V.GREENLNK.net ([169.254.5.168]) by GLKXH0005V.GREENLNK.net ([10.109.2.36]) with mapi id 14.03.0248.002; Tue, 24 May 2016 09:58:45 +0100
From: "Dearlove, Christopher (UK)" <chris.dearlove@baesystems.com>
To: Vincent Roca <vincent.roca@inria.fr>, IESG <iesg@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "draft-ietf-manet-rfc6779bis.all@ietf.org" <draft-ietf-manet-rfc6779bis.all@ietf.org>
Thread-Topic: Sector review of draft-ietf-manet-rfc6779bis-05
Thread-Index: AQHRtYbBYQK/bSgCMkup8lbFjqMzAZ/HxjTA
Date: Tue, 24 May 2016 08:58:44 +0000
Message-ID: <B31EEDDDB8ED7E4A93FDF12A4EECD30D923B6E98@GLKXM0002V.GREENLNK.net>
References: <4673D914-BF52-4C1D-A559-64C1FBBE4FC2@inria.fr>
In-Reply-To: <4673D914-BF52-4C1D-A559-64C1FBBE4FC2@inria.fr>
Accept-Language: en-GB, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.109.62.6]
Content-Type: multipart/alternative; boundary="_000_B31EEDDDB8ED7E4A93FDF12A4EECD30D923B6E98GLKXM0002VGREEN_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/secdir/0Ipxng3zE8_7luMfj4vBjbxXkiE>
Subject: Re: [secdir] Sector review of draft-ietf-manet-rfc6779bis-05
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 May 2016 08:58:57 -0000
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: +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: Vincent Roca [mailto:vincent.roca@inria.fr] Sent: 24 May 2016 07:37 To: IESG; secdir@ietf.org; draft-ietf-manet-rfc6779bis.all@ietf.org 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. ********************************************************************
- [secdir] Sector review of draft-ietf-manet-rfc677… Vincent Roca
- Re: [secdir] Sector review of draft-ietf-manet-rf… Dearlove, Christopher (UK)