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

["Dearlove, Christopher (UK)" <[e-mail]>]

With regard to the experimental code points, I think one really is too low,
I can immediately see a requirement for two in something I may do, and
I can imagine more. I would suggest at least four, possibly more. Would
that be  more palatable by making these Private as well as (or instead of?)
Experimental use?

-- 
Christopher Dearlove
Technology Leader, Communications Group
Communications and Networks Capability
BAE Systems Advanced Technology Centre
West Hanningfield Road, Great Baddow, Chelmsford, CM2 8HN, UK
Tel: [phone]  Fax: [phone]

BAE Systems (Operations) Limited
Registered Office: Warwick House, PO Box 87,
Farnborough Aerospace Centre, Farnborough, Hants, GU14 6YU, UK
Registered in England & Wales No: 1996687

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Adrian Farrel
Sent: 07 January 2012 20:13
To: [e-mail]
Cc: [e-mail]
Subject: [manet] AD review of draft-ietf-manet-packetbb-sec


                    *** WARNING ***

  This message has originated outside your organisation,
  either from an external partner or the Global Internet. 
      Keep this in mind if you answer this message.
  To report a suspicious email, follow the instructions 
  on the Global Intranet at "<How We Work> / <Security>"


 

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.

_______________________________________________
manet mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/manet


********************************************************************
This email and any attachments are confidential to the intended
recipient and may also be privileged. If you are not the intended
recipient please delete it from your system and notify the sender.
You should not copy it or use it for any purpose nor disclose or
distribute its contents to any other person.
********************************************************************