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

[Barry Leiba <[e-mail]>]

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)?

-- 
Barry