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

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

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.