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

From: "Adrian Farrel" <[email-masked]>
Date: Sat, 7 Jan 2012 20:12:37 -0000

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.

---

From: "Adrian Farrel" <[email-masked]>
Date: Mon, 9 Jan 2012 17:06:59 -0000

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

A

> -----Original Message-----
> From: Adrian Farrel [mailto:[email-masked]]
> Sent: 07 January 2012 20:13
> To: [email-masked]
> Cc: [email-masked]
> Subject: AD review of draft-ietf-manet-packetbb-sec
>

---

From: "Dearlove, Christopher (UK)" <[email-masked]>
Date: Tue, 10 Jan 2012 12:34:32 -0000

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: +44 1245 242194  Fax: +44 1245 242124

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: [email-masked] [mailto:[email-masked]] On Behalf Of Adrian Farrel
Sent: 07 January 2012 20:13
To: [email-masked]
Cc: [email-masked]
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,
Adrian

---

ï»¿

---

---

---

Section 11

---

Section 12.1.1

---

12.1.1

---

Section 13

---

_______________________________________________
manet mailing list
[email-masked]
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.
********************************************************************

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 10 Jan 2012 21:29:30 -0000

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

> From: Dearlove, Christopher (UK) [mailto:[email-masked]]
> Sent: 10 January 2012 12:35
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: [manet] AD review of draft-ietf-manet-packetbb-sec
>

---

From: Ulrich Herberg <[email-masked]>
Date: Tue, 31 Jan 2012 11:59:11 -0800

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 )

> (A piece of pettiness, but citations cannot be made from the stand-alone

done

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

> an RFC. You can "define" things if you feel the need for a word.

Done

> I suggest removing the second motivation.

Okay, I did that.

> s/TLV is, that/TLV is that,/

done

> considerations section. It is typical to request IANA to perform actions.

Done. Does this also apply to section 13.1?

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

Best regards
Ulrich