Re: [secdir] SecDir review of draft-ietf-anima-grasp-09

[Brian E Carpenter <[e-mail]>]

Thanks Barry. Good comments, but we have to get a new draft out
before the deadline, so I'm not sure these will all make it in
until the one after.

Regards
   Brian

On 08/03/2017 15:43, Barry Leiba wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.
> 
> First, I'm sorry this review is a few days late, and I hope that isn't
> a problem.
> 
> Second, the document is "ready with issues".  Most of the comments
> below are minor, and editorial.  The three that are substantive are:
> 
> 1. SHOULD vs MUST with respect to encryption in Sections 3.5.1 and 3.5.2.1.
> 
> 2. The UTF-8 issues in Section 3.10.1.
> 
> 3. Guidance for the Designated Expert in Section 7.
> 
> These should all be easy to resolve.
> 
> — Section 1 —
> 
>    A reference model
>    for autonomic networking on this basis is given in
>    [I-D.ietf-anima-reference-model].  The reader should consult this
>    document to understand how various autonomic components fit together.
> 
> Even though that document is an informative reference, I find it odd
> that the draft that helps us understand how this all fits together. .
> . is an expired draft.  It makes me wonder how well baked things are.
> 
> — Section 3.1 —
> 
>    The following additional terms are used throughout this document:
> 
>    o  Autonomic Device: identical to Autonomic Node.
> 
> It’s not a big point, but: Why?  Why is it important or useful to
> specifically define a *new* term in this document that has the same
> meaning as a similar term that’s already defined?
> 
> And, actually, now that I check, I see that “autonomic devices” is
> used in exactly one place, in the Abstract.  I suggest changing the
> term in the abstract to “autonomic nodes”, and removing this
> definition.
> 
> — Section 3.2 —
> 
>    Because GRASP needs to work whatever happens, especially during
>    bootstrapping and during fault conditions, it is essential that every
>    implementation is as robust as possible.
> 
> There seems to be a missing word, or some such; I can’t parse “GRASP
> needs to work whatever happens”.  And picky grammatical nit:
> subjunctive mood is needed with “essential”, so it should be “it is
> essential that every implementation be as robust as possible.”
> 
> — Section 3.3 —
> 
>       GRASP
>       provides mechanisms to guarantee convergence (or failure) in a
>       small number of steps, i.e. a timeout and a maximum number of
>       iterations.
> 
> Another nit. This is an outstanding example of why I don’t like to use
> “i.e.”: in this case, it leaves me wondering whether that’s really an
> exhaustive list, or whether you meant “e.g.”.  And, to me, it reads
> awkwardly anyway.  I suggest one of these alternatives (the sorts that
> can pretty much always stand in for the overused and unnecessary
> “i.e.”):
> 
> NEW-1
>       GRASP
>       provides two mechanisms to guarantee convergence (or failure)
>       in a small number of steps: a timeout and a maximum number of
>       iterations.
> 
> NEW-2
>       GRASP
>       provides a timeout and a maximum number of iterations,
>       which together guarantee convergence (or failure) in a
>       small number of steps.
> 
> — Section 3.5.1 —
> 
>    If there is no ACP, the protocol MUST use another form of strong
>    authentication and SHOULD use a form of strong encryption.  See
>    Section 3.5.2.1 for further discussion.
> 
> Both here and in 3.5.2.1: Why is encryption SHOULD, and not MUST?
> Looking ahead to 3.5.2.1, how could it be considered safe to use a
> network configuration protocol across administrative boundaries
> without encryption?
> 
> — Section 3.5.2.2 —
> 
>       A responder
>       SHOULD NOT send a Discovery Response message unless it cannot be
>       avoided.
> 
> Any clue about why it might be possible that it “cannot be avoided”?
> 
> — Section 3.5.2.3 —
> 
>    o  Any type of GRASP message MAY be sent.
> 
> This doesn’t feel like a “MAY” to me.  You’re not saying that there’s
> a protocol choice here, and how to handle it is optional and up to the
> implementation.  You’re saying that all types of GRASP messages are
> permitted when you’re using a SONN instance.  So maybe, “All types of
> GRASP messages are permitted.”
> 
> — Section 3.10.1 —
> 
>    All objectives are identified by a unique name which is a case-
>    sensitive UTF-8 string.
> 
> Actually, “case-sensitive” isn’t a sufficient descriptor for UTF-8, as
> there are issues of canonicalization and normalization, and the fact
> that languages differ in whether “case” makes sense at all.  This
> would be a bigger issue if you wanted case insensitivity, but as it is
> I think the fix is easy: you should just say that the name is a UTF-8
> string that is compared byte by byte.  This will have the effect of
> being case sensitive when that makes sense, and will also eliminate
> the issues of canonicalization and normalization: different ways of
> representing characters such as “ä” and “ô” and “é” will compare as
> different, and as these are protocol elements and not user strings,
> that should be fine.
> 
> The other question is whether there are any restrictions on what
> Unicode characters can be represented.  You make the colon a special
> character but give no other restrictions, so an objective name could
> include space characters (and various related Unicode characters such
> as tab, EN SPACE, ZERO WIDTH SPACE, and ZERO WIDTH NON-JOINER),
> control characters (FORM FEED, CARRIAGE RETURN, and the like),
> characters from every character set and language including Cuneiform
> and Egyptian Hieroglyphs, and even such iconic characters as MUSICAL
> SYMBOL G CLEF, ONCOMING POLICE CAR, and the famous PILE OF POO.  If
> that’s all OK, then that’s fine (and maybe it is, as, again, this is a
> protocol element, not a user string).  I just want to make sure you
> thought about it.
> 
> — Section 7 —
> 
> The creation of the Specification Required registry for the Objective
> Names Table needs to specify guidance for the Designated Expert (see
> draft-leiba-cotton-iana-5226bis, Sections 4.6 and 4.5).  It doesn’t
> have to be a lot, but it needs to be clear for future DEs who might
> not have been involved with developing this document what they need to
> consider as they review registration requests.  Why might they push
> back on a registration request?  Should they, for example, allow
> registration requests for two different Objective Names of “frobozz”
> and “Frobozz”?  What sort of documentation is sufficient for a
> registration (is “enough that you think implementations can be written
> from it” good enough, or are there specific things that the
> documentation ought to contain)?
>