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

[Ulrich Herberg <[e-mail]>]

Adrian,

thank you very much for your review. My comments are inline (which are
reflected in the new revision
http://www.ietf.org/id/draft-ietf-manet-packetbb-sec-08.txt )

On Sat, Jan 7, 2012 at 12:12 PM, Adrian Farrel <[e-mail]> wrote:
>
> 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)



done

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


No, I have added it in Section 10.1. Thanks for spotting this!


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

Done

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

Okay, I did that.


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

done

>
> ---
>
> Section 13
>
> Please remove the RFC2119 language from this part of the IANA
> considerations section. It is typical to request IANA to perform actions.

Done. Does this also apply to section 13.1?

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

>From the follow-up discussion of this, we reduced it to a range of 4.

Best regards
Ulrich