[secdir] SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03

Yoav Nir <ynir@checkpoint.com> Wed, 31 July 2013 23:20 UTC

Return-Path: <ynir@checkpoint.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id BE12021E8085; Wed, 31 Jul 2013 16:20:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.526
X-Spam-Status: No, score=-10.526 tagged_above=-999 required=5 tests=[AWL=0.073, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id H5kej99ozTpR; Wed, 31 Jul 2013 16:19:59 -0700 (PDT)
Received: from smtp.checkpoint.com (smtp.checkpoint.com []) by ietfa.amsl.com (Postfix) with ESMTP id 1021B21E805F; Wed, 31 Jul 2013 16:19:56 -0700 (PDT)
Received: from DAG-EX10.ad.checkpoint.com ([]) by smtp.checkpoint.com (8.13.8/8.13.8) with ESMTP id r6VNJpkx032767; Thu, 1 Aug 2013 02:19:51 +0300
X-CheckPoint: {51F99B97-5-1B221DC2-1FFFF}
Received: from IL-EX10.ad.checkpoint.com ([]) by DAG-EX10.ad.checkpoint.com ([]) with mapi id 14.02.0342.003; Thu, 1 Aug 2013 02:19:50 +0300
From: Yoav Nir <ynir@checkpoint.com>
To: "secdir@ietf.org" <secdir@ietf.org>, IESG IESG <iesg@ietf.org>, "draft-ietf-manet-nhdp-olsrv2-sec.all@tools.ietf.org" <draft-ietf-manet-nhdp-olsrv2-sec.all@tools.ietf.org>
Thread-Topic: SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03
Thread-Index: AQHOjkRzWPcMempN206ICOIpPpticQ==
Date: Wed, 31 Jul 2013 23:19:49 +0000
Message-ID: <332E771E-87A4-4C9F-83B7-CB96AB41D5A3@checkpoint.com>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-kse-antivirus-interceptor-info: scan successful
x-kse-antivirus-info: Clean
x-cpdlp: 1158ae557a72b52e8ad5f2391fce785804ff27dc8f
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <9C422FCAE932E2438969B53166558749@ad.checkpoint.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [secdir] SecDir Review of draft-ietf-manet-nhdp-olsrv2-sec-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
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: <http://www.ietf.org/mail-archive/web/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: Wed, 31 Jul 2013 23:20:05 -0000

Do not be alarmed.  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: Has issues. This document needs some more work, both on the security considerations section and general terminology.

This draft adds integrity protection and replay protection to the NHDP protocol and the OLSRv2 protocol. These protocols use the TLV format defined in RFC 5444. This draft specifies the use of the ICV and TIMESTAMP TLVs (both defined in draft-ietf-manet-rfc6622-bis), the former for integrity protection, and the latter for replay protection.

I am not convinced by the suitability of a POSIX timestamp (32-bits with 1-second resolution) to protect in general against replay. Within the same second, a packet can be replayed. I don't know enough about the NHDP and OLSRv2 protocols to say whether this is a problem. Its usefulness depends on synchronized clocks, but this is well explained in the document, both in the security considerations, and in the regular sections where timestamp is mentioned.

The biggest hole in this specification is that it is silent about key distribution ("This framework does not...Specify how to distribute cryptographic material (shared secret key(s))." This is the real hard problem, and the draft doesn't even reference some other specification that does have a suitable key distribution protocol. You can't do HMAC without key distribution being in place.

On to the security considerations section:
This section is generally well-written, although it might have been clearer to write the limitations along with the list of alleviated attacks. The section does cover the dependency on clock synchronization, the limited time in which replay is possible, the vulnerability to other routers who possess the same shared key, and the reliance on another key distribution and key revocation mechanism.

About the general writing: 
This document contains some examples of sloppy language:
- Figure 1 shows messages being processed by "this specification". Specifications don't process messages. Hardware or software components do. 
- Section 3 says that "[RFC6130] and [OLSRv2] enable extensions to recognize…". Extensions don't recognize, they're just a string of bytes. Implementations recognize things.
- Section 4 says something about "messages owned by [RFC6130] and [OLSRv2]". Again, RFCs define messages, they don't own them.
- TC is used multiple times, but never expanded.