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

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 <Kathleen.Moriarty.ietf@gmail.com> wrote:
> 
> 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."
> 
> 
> _______________________________________________
> manet mailing list
> manet@ietf.org
> https://www.ietf.org/mailman/listinfo/manet