[manet] Kathleen Moriarty's No Objection on draft-ietf-manet-olsrv2-sec-threats-03: (with COMMENT)

"Kathleen Moriarty" <Kathleen.Moriarty.ietf@gmail.com> Thu, 05 January 2017 03:13 UTC

Return-Path: <Kathleen.Moriarty.ietf@gmail.com>
X-Original-To: manet@ietf.org
Delivered-To: manet@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D0FE512987C; Wed, 4 Jan 2017 19:13:27 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Kathleen Moriarty" <Kathleen.Moriarty.ietf@gmail.com>
To: "The IESG" <iesg@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.40.3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <148358600785.13006.4415679112806345898.idtracker@ietfa.amsl.com>
Date: Wed, 04 Jan 2017 19:13:27 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/manet/w5e93mMGap0HaJMUJ6RqivsUhDo>
Cc: manet-chairs@ietf.org, manet@ietf.org, draft-ietf-manet-olsrv2-sec-threats@ietf.org
Subject: [manet] Kathleen Moriarty's No Objection on draft-ietf-manet-olsrv2-sec-threats-03: (with COMMENT)
X-BeenThere: manet@ietf.org
X-Mailman-Version: 2.1.17
List-Id: Mobile Ad-hoc Networks <manet.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/manet>, <mailto:manet-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/manet/>
List-Post: <mailto:manet@ietf.org>
List-Help: <mailto:manet-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/manet>, <mailto:manet-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 05 Jan 2017 03:13:28 -0000

Kathleen Moriarty has entered the following ballot position for
draft-ietf-manet-olsrv2-sec-threats-03: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


The SecDir reviewer makes a good point on the draft not covering delays
and that replay mechanisms will defend against the attack described in
different ways.  The review is linked off the draft.  Please ket me know
if there is a reason to not add this threat or if you have text to
propose to address it.

Full review:

Relevant section for convenience:
"One issue that I did not see discussed in the draft would be for the
attacker to effectively delay packets.  For example, the attacker
captures packets while jamming to prevent some stations from receiving
packets.  The attacker can collect a sequence of traffic and replay at a
later time, with different timing and in a different location.  Not all
replay mechanisms will defend against this attack int he same way. 
Sequence number validation (which appears to be allowed  in 7183) may not
be as effective as timestamps, depending upon the time skew allowed.  The
document does discuss timestamps , but I think it should probably make
the following clearer:

There are several places in sections 4 and 5 where the document says
something like "This kind of attack can be mitigated using integrity
check mechanisms".  I think in most of these instances replay protection
is also important.  One solution would be to remove these instances and
just relay on section 6.2 which has a better description of the available
protections.   Since it seems that the integrity check could be deployed
with just sequence number instead of timestamps it might be good to
mention that it is important to include and verify timestamps for replay