Re: [manet] AD review of draft-ietf-manet-packetbb-sec

["Adrian Farrel" <[e-mail]>]

Please ignore the issue with spurious characters. This appears to be a tools
bug.

A

> -----Original Message-----
> From: Adrian Farrel [mailto:[e-mail]]
> Sent: 07 January 2012 20:13
> To: [e-mail]
> Cc: [e-mail]
> Subject: AD review of draft-ietf-manet-packetbb-sec
> 
> Thanks for this draft. I have performed my AD review as usual and I
> don't have any major issues.
> 
> Before we start, one minor question to help me set my expectations...
> 
> Did you have any expert security input on this work? I only ask in
> order to try to work out what level of review we are likely to get
> later in the process.
> 
> Otherwise I have a few nits and minor requests to polish the document.
> I hope they are straight forward and you can quickly spin a new
> revision of the document which I can advance to IETF last call.
> 
> Thanks,
> Adrian
> 
> ---
> 
> The text file I downloaded has a couple of interesting characters at the
> top.
> 
> 
> 
> ---
> 
> Could you s/[RFC5444]/defined in RFC 5444/
> 
> (A piece of pettiness, but citations cannot be made from the stand-alone
> Abstract)
> 
> ---
> 
> Section 10.1 does not include the caveat about other signatures that may
> already be present as found in 8.1 and 9.1. Is this intentional?
> 
> ---
> 
> Section 11
> 
> Don't "propose" anything! This is an I-D you plan to have converted into
> an RFC. You can "define" things if you feel the need for a word.
> 
> ---
> 
> Section 12.1.1
> 
>    The rationale for separating the hash function and the cryptographic
>    function into two octets instead of having all combinations in a
>    single octet - possibly as TLV type extension - is twofold: First, if
>    further hash functions or cryptographic functions are added in the
>    future, the number space might not remain continuous.  More
>    importantly, the number space of possible combinations would be
>    rapidly exhausted.  As new or improved cryptographic mechanism are
>    continuously being developed and introduced, this format should be
>    able to accommodate such for the foreseeable future.
> 
> I accept the reasoning for the contiguity. I don't accept the reasoning
> for number space exhaustion. Surely, you have the same number of bits
> (16) and the same amount of information (#hashfuncs * #cryptofuncs).
> 
> Actually, in your method exhaustion is slightly more likely because you
> only have 8 bits for each category and so one of them could become
> exhausted independent of the other.
> 
> I suggest removing the second motivation.
> 
> Clarity of separation of function identifiers would serve as a second
> reason if you must have one.
> 
> ---
> 
> 12.1.1
> 
>    The rationale for not including a field that lists parameters of the
>    cryptographic signature in the TLV is, that before being able to
>    validate a cryptographic signature, routers have to exchange or
> 
> s/TLV is, that/TLV is that,/
> 
> ---
> 
> Section 13
> 
> Please remove the RFC2119 language from this part of the IANA
> considerations section. It is typical to request IANA to perform actions.
> 
> ---
> 
> Sections 13. through 13.6
> 
> The experimental ranges here are way too large unless you can give me a
> really good reason.
> 
> Understandable as MANET moves from experimental to standards track, but
> once you are standards track it is normal to restrict the experimental
> ranges to a very small (e.g. one) range of numbers. Have a look at
> RFC 3692. Consider whether it would be enough to have just one or two
> code points reserved for experimentation.