Re: [manet] Review of draft-ietf-manet-olsrv2-sec-threats-03

Christopher Dearlove <christopher.dearlove@gmail.com> Mon, 19 December 2016 20:06 UTC

Return-Path: <christopher.dearlove@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1FA1C129572; Mon, 19 Dec 2016 12:06:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ogkdC4XS4nHG; Mon, 19 Dec 2016 12:06:26 -0800 (PST)
Received: from mail-wm0-x243.google.com (mail-wm0-x243.google.com [IPv6:2a00:1450:400c:c09::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 655021294B6; Mon, 19 Dec 2016 12:06:26 -0800 (PST)
Received: by mail-wm0-x243.google.com with SMTP id u144so20556358wmu.0; Mon, 19 Dec 2016 12:06:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iebPvRVNN2TfxvRmC6GlBkwosK3y22KL6E7e/nF/EcY=; b=rdBFKXANAEw/mLclKf6nG1xEc4RBbvQS78h/HyUSExzmazHb0abfLTxz6nfRRHofad RqO0FkkMwO7UBoyNWPAGP2zEoauGY/IRI45d9jObySI4t+x6a8DJAoUkzXdzqxbQ/U8D wigo0dWSS0itD7IqpXFpDxDu0sSLbCMTRkaC0tFk54kdi3F8Zku3rwR9k11k2/b96Y4e PqE9oBNm4+emkOKF5pKQYvnuGkFFtfPQQ7sBEuEjmK7nn+O+q/gwbHuY+b+NHqMQEzur t5GHI7RSAQwgcdDti021TbY895gnMA1xTtsvVuuuwKBdyCi4K517O19MbwcQaTK4j0zw NJHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=iebPvRVNN2TfxvRmC6GlBkwosK3y22KL6E7e/nF/EcY=; b=na1vwa3EokG+SaYVCdW0Lf5DCr/R8xb7vrc9iC2pQDt9cQ6+tXsT9hVS4hgL/a9Fb1 uQFlcaRBHrC4lskXroFFUEOUnelbXCqPBVNnXuCzN5Zp5/AgalSle5QtChtKXizfqrX6 XVOWdm2zJ+pW6FPdrt9iK9GS8CKd36EMNzHJdZvJ0Tmp03TJ0nU51aQw6CKGaD1YGhgU x3Y6F/IRhN7tpaKq2/5YZuBk6SqXVj1HnGekPiDxAQbZHgn0PyVp6WA9fxs1jKVr09i9 GtYkhFTCVwVIJshyeReHiAd1TU1mX6mK6vmmtwzanCREt5L1vcw0HFnQlukJeyBQToQN c8Hw==
X-Gm-Message-State: AIkVDXLJMhVOcz7/mpkCSfwrUsR3k3ugX6urvyv897g5fZT/tgWxJhNFdf2n1+1+FMJsvA==
X-Received: by 10.28.46.144 with SMTP id u138mr14091448wmu.136.1482177984756; Mon, 19 Dec 2016 12:06:24 -0800 (PST)
Received: from [192.168.1.142] ([213.205.251.189]) by smtp.gmail.com with ESMTPSA id m145sm18711427wma.3.2016.12.19.12.06.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 19 Dec 2016 12:06:24 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: [manet] Review of draft-ietf-manet-olsrv2-sec-threats-03
From: Christopher Dearlove <christopher.dearlove@gmail.com>
In-Reply-To: <CADnDZ8_0oUg5iPTpHuBeQifHfot8E=LHa9qdTsHeHcimq8BfkQ@mail.gmail.com>
Date: Mon, 19 Dec 2016 20:06:22 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <277CA497-CFB1-4E23-9941-66D89C3BBB1D@gmail.com>
References: <148209096399.6405.5288912281902695282.idtracker@ietfa.amsl.com> <B31EEDDDB8ED7E4A93FDF12A4EECD30DA51A49AC@GLKXM0003v.GREENLNK.net> <CADnDZ8_0oUg5iPTpHuBeQifHfot8E=LHa9qdTsHeHcimq8BfkQ@mail.gmail.com>
To: Abdussalam Baryun <abdussalambaryun@gmail.com>
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/OwadUy2A0hJtJYBWtLshocFjzU8>
Cc: "ietf@ietf.org" <ietf@ietf.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "manet@ietf.org" <manet@ietf.org>, "draft-ietf-manet-olsrv2-sec-threats.all@ietf.org" <draft-ietf-manet-olsrv2-sec-threats.all@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Dec 2016 20:06:28 -0000

On 19 Dec 2016, at 19:39, Abdussalam Baryun <abdussalambaryun@gmail.com> wrote:
> 
> I recommend that if a reviewer did not find the answer to the simple security question then the answer should be clear in the document. Please note that this protocol has many RFCs involved but still this draft needs to answer clearly the security threat questions. I think maybe the confusion is that the draft refers to many drafts and does not clarify the differences between packets and messages, not sure but the reviewer can help with his observations. The main issues of threats is always about packets and messages, so why not clarify those differences rather than referring to other documents.
> 
> - We may understand from the below answer is that the question answer is YES, and  NO if using ICVs or signatures. It states in the draft in page 4, as OLSRv2 SHOULD use 7183 and MAY use other ....... (it is better not to use MAY if you don't define/determine the other alternative). 
> 
> - Section 3.2 page 7,  mentions the attacks threats of modify hop-limit. It also mentions that hop-limit is not protected by integrity check,,, ( which is  7183).
> 
> Recommend to clarify in draft:
> The manet packet has no longer than one hop, it's messages that have the hop-limit that may be attacked. So the attacker to manet using 7183,  just can change the hop-limits of messages if has the keys.

There are a number of errors in the above, which I’m afraid I lack the patience to spell out in detail.

But it does correctly point out that section 3.2 discusses the impact of attacks on hop count/limit - in fact in more detail than I did. And that this is not protected against by 7183 is indicated in section 6.2.1. (The keys are not required.)

However there is a weakness in section 6, which is that it seems to only be considering message ICV use. But, as I had forgotten in my previous comment, although RFC 7182 defines packet and message level protections, RFC 7183 only discusses the message protection. (That will be because packets are RFC 5444 constructs, not limited to carrying OLSRv2 and NHDP.) Packet level protection therefore is correctly excluded if only considering RFC 7183, however I think a mention of packet protection using RFC 7182 would not be out of place. (Protecting hop count and limit is the main gain from packet protection over message protection, the other is some processing gain if using something more expensive like RFC 7859 - an RFC 7182 addition. The main losses are in trust model and the impact of key loss when not using a single shared key - as for RFC 7859 but not RFC 7183’s chosen option from RFC 7182.)