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

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

Hi Chris,

If it is an experiment I believe we should call it such (i.e. something we might
later bring back and standardise [or possibly put in the trash]). I think that
MANET has a proud tradition of doing experimental work and sorting the wheat
from the chaff. Few WGs come close to doing it better.

We can negotiate on the number of code points. Usually it turns out that one is
enough, because everything else can be hung on subcodes. But I could live with
four.

A

> -----Original Message-----
> From: Dearlove, Christopher (UK) [mailto:[e-mail]]
> Sent: 10 January 2012 12:35
> To: [e-mail]; [e-mail]
> Cc: [e-mail]
> Subject: RE: [manet] AD review of draft-ietf-manet-packetbb-sec
> 
> 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.
> **************************************************************
> ******