Re: [Gen-art] Review: draft-ietf-ipsecme-ddos-protection-09

Valery Smyslov <svan@elvis.ru> Tue, 27 September 2016 16:05 UTC

Return-Path: <svan@elvis.ru>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2F1812B228; Tue, 27 Sep 2016 09:05:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.562
X-Spam-Level:
X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-2.316, STOX_REPLY_TYPE=0.439, TVD_FINGER_02=1.215] autolearn=ham autolearn_force=no
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 7ec40_2WqPjZ; Tue, 27 Sep 2016 09:05:19 -0700 (PDT)
Received: from fish.elvis.ru (fish.elvis.ru [82.138.51.18]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1B4A612B283; Tue, 27 Sep 2016 09:05:18 -0700 (PDT)
Received: from [10.111.1.40] (helo=robin.office.elvis.ru) by fish.elvis.ru with esmtp (Exim 4.76) (envelope-from <svan@elvis.ru>) id 1bouqc-0000Hf-8F; Tue, 27 Sep 2016 19:03:10 +0300
Received: from buildpc (10.111.10.31) by robin.office.elvis.ru (10.111.1.40) with Microsoft SMTP Server id 14.3.301.0; Tue, 27 Sep 2016 19:03:13 +0300
Message-ID: <9592EF6496B5461CAA97C6658A9228C4@buildpc>
From: Valery Smyslov <svan@elvis.ru>
To: Jari Arkko <jari.arkko@piuha.net>, Lucy yong <lucy.yong@huawei.com>, draft-ietf-ipsecme-ddos-protection@ietf.org
References: <2691CE0099834E4A9C5044EEC662BB9D572DA459@dfweml501-mbb> <64B5C794-127F-44F7-87BC-E24F07349452@piuha.net>
Date: Tue, 27 Sep 2016 19:03:07 +0300
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"; charset="windows-1252"; reply-type="original"
Content-Transfer-Encoding: 8bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157
Archived-At: <https://mailarchive.ietf.org/arch/msg/gen-art/OXTErdll-nEeTjaFWoq_UpflILQ>
Cc: General Area Review Team <gen-art@ietf.org>
Subject: Re: [Gen-art] Review: draft-ietf-ipsecme-ddos-protection-09
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2016 16:05:24 -0000

Hi Lucy,

thank you for the review. Please find comments below.
I snipped those typos/grammar issues which I completely agree with.

> On 24 Sep 2016, at 00:28, Lucy yong <lucy.yong@huawei.com> wrote:
> I am the assigned Gen-ART reviewer for this draft. The General Area Review Team (Gen-ART)
> reviews all IETF documents being processed by the IESG for the IETF Chair.
> Please treat these comments just like any other last call comments.
>
> For more information, please see the FAQ at
>
> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>
> Document: draft-ietf-ipsecme-ddos-protection-09
>      Multi-Path Time Synchronization
> Reviewer: Lucy Yong
> Review Date: 23-Sept-2016
> IETF LC End Date: 28-Sept-2016
> IESG Telechat date: 29-Sept-2016
>
> Summary: This document is nearly ready for publication as a standard track RFC. Some minor comments. Some nits need to 
> be corrected.
>
> PS: comment for IESG. The document specifies puzzles approach and related protocol to boost the difficulty for DDoS 
> attacks.
> The protocol description is simple and short; however it spends many pages (section 7) to describe the processes
> at the Initiator and the Responder. Maybe in future IETF can consider accepting protocol software code in a RFC.
> This will be easier for author and no need for programmers to read the description and program it (sure they will not 
> come out the same program logic).
>
> Major issues: N/A
>
> Minor issues:
>
> Section 1: 2nd paragraph, bot-nets,
> Comment: what is the bot-nets?

We meant botnets. The term is rather new, so I'm not sure which spelling
is more common. If we use "botnets" instead will it be OK?

> Section 7.1.1.2, 1st paragraph
> Comment: “that must be used”, should it be “that MUST be used” or “that is used”?

Actually “that MUST be used” is correct. However, section 8.1 contains description of
PUZZLE notification format and this MUST is more appropriate there.
So, I think it is possible to use “that is used” here and an uppercase MUST
in 8.1 to not duplicate same requirements. Is it OK?

> Nits/editorial comments:
>
> Section 6:
>
> s/the puzzle difficulty should/the puzzle difficulty SHOULD/

OK.

> Section 7.1
>
> s/the IKE Responder should/the IKE Responder SHOULD/

OK.

> Section 7.1.1.1
> s/the level should/the level SHOULD/

OK.

> Section 7.1.1.2
> s/this type must/this type MUST/

I disagree here. It is IKEv2 core specification that imposes
this MUST, we are just use this feature. This lowercase
must means that if the parties follow RFC7296, then
at least one PRF transform will always be in SA payload.

What about the following?
s/this type must always be present/this type is always present/

> Section 7.1.1.3
> s/should/SHOULD/ (3 places)

OK.

> s/blob/block/

OK, but is there any difference?

> s/may continue to generate/MAY continually generate/

I partially disagree here. From my understanding "continually"
means constantly. The idea of the sentence is that
the Responder may generate cookie as suggested
in RFC 7296 instead of using method described above.
I don't see how "continually" fits here.

What about the following?
s/may continue to generate/MAY generate/

> Section 7.1.4
> s/must/MUST/ (2 places)

There are more than 2 lowercase must. I guess you mean:

s/it must be processed according/it MUST be processed according/
s/The Responder must take the smallest number/The Responder MUST take the smallest number/

If I guessed correctly, then OK.

> Section 7.2
> s/The Responder should/The Responder SHOULD/

OK.

> Section 8.1
> s/PRF must/PRF MUST/

OK.

> Section 9
> s/Initiators should/Initiators SHOULD/

OK.

> Section 10
> s/Care must/Care MUST/

I'm hesitating. In my opinion uppercase MUST is not applicable here,
because it is an introductory sentence and MUST here is too vague.
There are more detailed RECOMMENDED below.

Regards,
Valery Smyslov.