[secdir] SECDIR review of draft-ietf-manet-nhdp-sec-threats-04

Matthew Lepinski <mlepinski.ietf@gmail.com> Mon, 10 June 2013 04:13 UTC

Return-Path: <mlepinski.ietf@gmail.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 6695C21F8B90; Sun, 9 Jun 2013 21:13:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNGuXL9wIxIw; Sun, 9 Jun 2013 21:13:26 -0700 (PDT)
Received: from mail-qe0-f54.google.com (mail-qe0-f54.google.com [209.85.128.54]) by ietfa.amsl.com (Postfix) with ESMTP id ABE0321F8AC2; Sun, 9 Jun 2013 21:13:26 -0700 (PDT)
Received: by mail-qe0-f54.google.com with SMTP id ne12so3802452qeb.13 for <multiple recipients>; Sun, 09 Jun 2013 21:13:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=+NzIt9DP7hTcy2jEQTh7LEZ/XM25SqoXclVVv60eF6U=; b=fvdq/FakIMgh4R0SsYp5g8wvaFbg6pu0aI2yi9ofQOXYu7HwmYal/96br6gPXOFN9e NxMECqb7yJRoLQ3gjiwxzyNxc8yjXEOmspxC7ourRf+gl0pCo+aZxMWIHd428xlUaKVD mThnE/oAsRCEJR7PMaceWmUM9v81qIkKtYUySeR9C70qMJQDqFLwSMitEgnyN7FSqiLa V2BBvOkUe67FoK9Q6yW/1tYsaqCwB1rzf0XrX1iiacWysivBGwpuHxTABkHNcfjn+Mqc arBIvkNcAxEP9raXT22HfmA7efipkbXOOs84/xLEz+QOGsKcIAhlik0dKgdRPYJqzmxJ lpsQ==
MIME-Version: 1.0
X-Received: by 10.229.24.198 with SMTP id w6mr452903qcb.37.1370837606125; Sun, 09 Jun 2013 21:13:26 -0700 (PDT)
Received: by 10.49.1.43 with HTTP; Sun, 9 Jun 2013 21:13:25 -0700 (PDT)
Date: Mon, 10 Jun 2013 00:13:25 -0400
Message-ID: <CANTg3aBH6T5Hqg84Me_-J9K0rfg9zZh+GHY_yVzNv66DKV7w+A@mail.gmail.com>
From: Matthew Lepinski <mlepinski.ietf@gmail.com>
To: "secdir@ietf.org" <secdir@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>
Content-Type: multipart/alternative; boundary=14dae9d70e748ed96f04dec5007b
Cc: draft-ietf-manet-nhdp-sec-threats@tools.ietf.org
Subject: [secdir] SECDIR review of draft-ietf-manet-nhdp-sec-threats-04
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: Mon, 10 Jun 2013 04:13:38 -0000

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.

This document provides a taxonomy of attacks against the Mobile Ad Hoc
Network Neighborhood Discovery Protocol (NHDP) [RFC 6130]. The document
also contains a discussion of the impact of these attacks on running on top
of NHDP (in particular, OLSRv2 and SMF)

Having reviewed the document, I do not see substantial issues in the
document. I believe it is reasonable to publish as an informational RFC.

*One minor issue:* The replay attack described in Section 4.5 did not seem
substantially different than the attacks described in Section 4.4. It is
not clear to me how replaying a message from another part of the network is
any worse (or substantially different) than just fabricating a message
claiming connectivity that does not exist (i.e., like what is described in
4.4.2). I would recommend either deleting 4.5 or else clarifying how these
attacks are substantially different.

*Trivial nit:* In Section 5, "a Compromised NHDP router will seek to
manipulate" -- substitute "may seek" instead of "will seek". We don't know
for certain what a compromised router will do (unless one assigns clear
motivation to the adversary, which this document does not).