Subject: Re: [Gen-art] review of draft-ietf-hip-dex-06.txt

From: Gonzalo Camarillo <[email-masked]>
Date: Mon, 5 Mar 2018 13:14:27 +0200

Bob, Rene,

could you please look into the review below and get back to Francis? Thanks!

Cheers,

Gonzalo

On 26/02/2018 7:30 PM, Francis Dupont 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
> 
> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
> 
> Document: draft-ietf-hip-dex-06.txt
> Reviewer: Francis Dupont
> Review Date: 20180224
> IETF LC End Date: 20180226
> IESG Telechat date: unknown
> 
> Summary: Ready
> 
> Major issues: None
> 
> Minor issues: None
> 
> Nits/editorial comments: 
>  - ToC page 3: you use the US spelling of Acknowledgments in the ToC
>   and the English one (acknowledgements) in the technical body.
>   Even when it is not very consistent I believe this follows RFC 7401
>   choice so I am fine with this.
> 
>  - 2.1 page 6: please add/move to RFC 8174 which updates RFC 2119 fixing
>   the keyword case silly issue.
> 
>  - 2.2 page 6: perhaps "sort" should be added here?
> 
>  - 2.3 page 7 (twice): (c.f.  Section 3)  -> (see Section 3) or
>   simply (Section 3)
> 
>  - 4.1.3.2 page 16 (at end of line): e.g. -> e.g.,
> 
>  - 5.3.3 page 25: I don't believe the critical property for
>   random value is to be "uniformly distributed" (for instance
>   I could have put "unpredictable"). I leave this to the security
>   directorate who should propose a better wording if they don't like
>   the current one...
> 
>  - 5.3.4 page 26: same comment.
> 
>  - 6.1 page 27: this section does not really explain what is the puzzle
>   (it only stands the equation to verify) but I remember the explaination
>   was before with a reference to 6.1 so I have no concern.
> 
>  - 6.2.1 sender 3 page 27: hidden dependency on the sort definition
>   for HOST_g/HOST_l so gl/lg keys. Yes it is in 6.3 but 6.3 is after.
> 
>  - 6.3 pages and 30: sort is used page 29 and defined after page 30,
>   this is why IMHO the question to move the definition to 2.2 notation
>   is a good one...
> 
>  - 6.3 page 30: / is not associative so ceil(L/RHASH_len/8) is bad.
>   The text shows it must be ceil(L/(RHASH_len/8)) (vs ceil((L/RHASH_len)/8))
> 
>  - 6.5 1. page 31: Otherwise, it must drop the packet. -> MUST
> 
>  - 6.6 1. page 33: the system should process the R1 packet -> or SHOULD
>   or (I prefer) the system processes the R1 packet
> 
>  - 6.6 8. page 34: The R1 packet may have the A-bit set -> can
>   (not better from a language point of view but clearer and BTW
>    used for instance in 6.10...)
> 
>  - 6.6 13. page 34: it may either resend an I1 packet -> MAY? (cf 11.)
> 
>  - 6.7 5. page 36: Otherwise, the system should process the received I2 ->
>   or SHOULD or (better) processes (and drop -> drops)
> 
>  - 6.7 15. page 37:
>      If the A-bit is set, the Initiator's HIT is anonymous and should
>      not be stored permanently. -> IMHO SHOULD NOT or directly MUST NOT
> 
>  - 6.9 page 39: If a NOTIFY packet is received in state I2-SENT, this
>    packet may be an I2 reception acknowledgement of the optional
>    -> replace "may be" by "can be" or (better) "is"
> 
>  - 7 page 40: Please put "If a Responder is not under high load, #K
>    SHOULD be 0." in its own paragraph (i.e. add a break before "If").
>    It makes clearer this sentence is a requirement when the text before
>    is the rationale.
> 
>  - 8 page 40: " either supports HIP DEX or HIPv2 must be able to detect"
>   -> MUST or "has to"
> 
>  - 8 pages 40 and 41: I think that the first and last paragraphs of
>   section 8 say the same thing. Should you keep both?
> 
>  - 9 page 41: I'd like to see a formal proof of the DEX protocol.
>   I believe you share this wish as you cite SIGMA.
> 
>  - 9 page 42: I'd like to go further and recommend (lower case) the
>   use of a RNG (vs PRNG) when available (hopefully no longer an exception).
> 
>  - 9 page 42: Hence, HIP DEX HITs should not be use -> SHOULD or
>   ought to?
> 
> Thanks
> 
> [email-masked]
>