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

From: Lucy yong <[email-masked]>
Date: Fri, 23 Sep 2016 21:28:30 +0000

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?

Section 7.1.1.2, 1st paragraph

Comment: "that must be used", should it be "that MUST be used" or "that is used"?

Nits/editorial comments:

Section 6:

s/the puzzle difficulty should/the puzzle difficulty SHOULD/

s/This will This will/This will/

Section 7.1

s/the IKE Responder should/the IKE Responder SHOULD/
s/that puzzles/puzzles/

Section 7.1.1.1
s/next to/nearly/
s/the level should/the level SHOULD/

Section 7.1.1.2
s/([RFC7696])/[RFC7696]/
s/with another, and negotiate/with another and negotiate/
s/an SA payload, containing/an SA payload containing/
s/this type must/this type MUST/

Section 7.1.1.3
s/should/SHOULD/ (3 places)
s/blob/block/
s/may continue to generate/MAY continually generate/

Section 7.1.3
s/the solution to the puzzle contain/the puzzle solution contains/
s/i.e./i.e.,/ (2 places)

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

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

Section 7.2.2
s/message, containing/message containing/

Section 7.2.4
s/operations i.e.  computing/operations, i.e., computing/

Section 8.1
s/PRF must/PRF MUST/

Section 9
s/Initiators should/Initiators SHOULD/

Section 10
s/Care must/Care MUST/

---

From: Jari Arkko <[email-masked]>
Date: Tue, 27 Sep 2016 17:38:39 +0300

Many thanks for the review, Lucy!

Authors, do take note of the comments.

Jari

On 24 Sep 2016, at 00:28, Lucy yong <[email-masked]> wrote:

> Comment: “that must be used”, should it be “that MUST be used” or “that is used”?
> 
> 
> Nits/editorial comments:
> 
> Section 6:
> 
> _______________________________________________
> Gen-art mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/gen-art

---

From: Valery Smyslov <[email-masked]>
Date: Tue, 27 Sep 2016 19:03:07 +0300

Hi Lucy,

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

> 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.
>
> 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:
>

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?

> 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?

> s/the puzzle difficulty should/the puzzle difficulty SHOULD/

OK.

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

OK.

> s/the level should/the level SHOULD/

OK.

> 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/

> 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/

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

> s/The Responder should/The Responder SHOULD/

OK.

> s/PRF must/PRF MUST/

OK.

> s/Initiators should/Initiators SHOULD/

OK.

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