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

From: "Kathleen Moriarty" <[email-masked]>
Date: Wed, 04 Jan 2017 19:13:27 -0800

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:
https://datatracker.ietf.org/doc/draft-ietf-manet-olsrv2-sec-threats/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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:
https://www.ietf.org/mail-archive/web/secdir/current/msg07028.html

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
protection."

---

From: Jiazi Yi <[email-masked]>
Date: Thu, 12 Jan 2017 00:41:34 +0100

Dear Kathleen,

Firstly, thanks very much for the review and comments. 

We discussed the replay attack RFC7186 (https://tools.ietf.org/html/rfc7186#section-4.5 <https://tools.ietf.org/html/rfc7186#section-4.5>, a normative reference of this document). And we updated the document as the SecDir suggested. 

Hopefully it addresses your concern. 

regards

Jiazi

> On 5 Jan 2017, at 04:13, Kathleen Moriarty <[email-masked]> wrote:
> 
> _______________________________________________
> manet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/manet