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

From: Barry Leiba <[email-masked]>
Date: Tue, 7 Mar 2017 21:43:07 -0500

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Mar 2017 16:44:19 +1300

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

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 8 Mar 2017 17:29:21 +1300

Well, I take that back. I think all these points can be slipped into
this week's update of the draft (I plan to submit that on Friday
NZ time).

> network configuration protocol across administrative boundaries

Input please, or else you will see this as an open issue in Chicago.

Personal opinion: encryption should be a MUST.

> control characters (FORM FEED, CARRIAGE RETURN, and the like),

Once we specify byte-by-byte comparison, do we need to worry about
this in a protocol document? If someone is silly enough to
specify an objective called 'example.org:Недостаточно握 déjà	vu
' do we care, in the protocol design?

Personal opinion: we don't need to say anything.

Regards
   Brian

---

From: Barry Leiba <[email-masked]>
Date: Wed, 8 Mar 2017 14:29:50 -0500

> Personal opinion: we don't need to say anything.

That's probably correct, and I just wanted to be sure y'all had
thought about it -- more whether there'd be an issue with
space-related characters or confusibles than about real non-Latin
languages or pile-of-poo icons.

Thanks for addressing my comments!

Barry

---

From: Michael Richardson <[email-masked]>
Date: Thu, 09 Mar 2017 09:49:47 -0500

> Personal opinion: encryption should be a MUST.

I believe that we will have situations where we have a secured ACP into a NOC
(to an edge router or VM hypervisor), and then we will have some unencrypted,
but secured links to platforms in transition.

It will be easy to add the GRASP daemon to answer resource requests to the
platform, but hard to add the ACP to that platform without a forklift
upgrade.

This is why I think it is a SHOULD, as much as I want it to transition to
being a MUST.

    > Once we specify byte-by-byte comparison, do we need to worry about this
    > in a protocol document? If someone is silly enough to specify an

It matters, when humans have to confirm things.  I think that objectives
will be mostly baked into code.  So, I agree with you, but I would rather
exclude all that UTF stuff too.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Mar 2017 11:53:59 -0500

> This is why I think it is a SHOULD, as much as I want it to transition to

This brings up a common rant that I have:
We should be putting into our protocol specs what we want the protocol
to be, not some compromise that comes from knowing that not everyone
will comply with everything from the start.

If the right thing is to say "MUST encrypt", but we know there'll be a
transition period during which that's not fully practical, then we
should say that.  Something like this added to Section 3.5.1:

NEW
In some cases there will be a transition period, in which it might not
be practical to run with strong encryption right away.  It's important
to keep this period as short as possible, and to upgrade to a fully
encrypted setup as soon as possible.
END

> exclude all that UTF stuff too.

That's true: if these really are protocol elements and there's no need
to have them Internationalized for human consumption, perhaps limiting
them to US-ASCII makes sense and avoids issues with odd character
effects (code that breaks if certain characters appear in strings, or
humans debugging things and being confused by characters that look the
same but are encoded differently).  On the other hand, if it really
would be handy to be able to define objective names in Chinese, Hindi,
or Hebrew, there's nothing wrong with sticking to UTF-8 as long as the
possibilities are understood and folks are OK with it.

Barry

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 10 Mar 2017 08:37:50 +1300

> encrypted setup as soon as possible.

or perhaps more precisely:

During initialization of nodes there will be a transition period...

Whether this is phrased as an exception to the MUST or as the justification
for ignoring the SHOULD is a matter of taste, I think.

> possibilities are understood and folks are OK with it.

My thought was that these names will sometimes be visible to humans so why
not allow localized names? If GRASP succeeds it might be used for local
applications, not just generic applications. So I'd rather allow it
from the start, and if we have to add character-set restrictions later,
so be it.

    Brian

---

From: Barry Leiba <[email-masked]>
Date: Thu, 9 Mar 2017 14:53:47 -0500

> During initialization of nodes there will be a transition period...

Yep; better.

> for ignoring the SHOULD is a matter of taste, I think.

I don't think it's a question of taste.  If there's a long-term reason
to run nodes without encryption, then SHOULD might make sense.  But if
we do expect the stable state to always be encrypted, and avoiding it
is a short-term expedient that we want to have go away as soon as
possible, then the protocol should say MUST, and the exception is
clearly specified as a brief thing that mustn't last.  It's a
substantive difference, not one of writing style.

> from the start, and if we have to add character-set restrictions later,

Makes sense to me.  Carry on.

Barry

---

From: Michael Richardson <[email-masked]>
Date: Fri, 10 Mar 2017 11:45:44 -0500

Brian E Carpenter <[email-masked]> wrote:
    >> NEW In some cases there will be a transition period, in which it might
    >> not be practical to run with strong encryption right away.  It's
    >> important to keep this period as short as possible, and to upgrade to
    >> a fully encrypted setup as soon as possible.  END

    > During initialization of nodes there will be a transition period...

Brian, by "initialization", do you mean bootstrapping?

    > Whether this is phrased as an exception to the MUST or as the
    > justification for ignoring the SHOULD is a matter of taste, I think.

I am saying that there will be a period where legacy NOC elements will be
placed into a kind of "ACP container" --- the ACP encryption will not
extended into the "operating system" where the NOC element is, but likely
terminated "in the stack" or "in the wire".

(cf: Bump in the Stack, Bump in the Wire
     https://tools.ietf.org/html/rfc4301#section-3.3
)

    > My thought was that these names will sometimes be visible to humans so
    > why not allow localized names? If GRASP succeeds it might be used for
    > local applications, not just generic applications. So I'd rather allow
    > it from the start, and if we have to add character-set restrictions
    > later, so be it.

Barry, is there a way to say, "UTF-8 without all the confusing parts"?
Is that what IDNxxxx is all about?

---

From: Barry Leiba <[email-masked]>
Date: Fri, 10 Mar 2017 13:02:17 -0500

> Is that what IDNxxxx is all about?

Kinda-sorta, but it won't quite work for this.  The high-order answer
is to reference IDNA 2008 (RFC 5892 will do) and say that characters
that are PVALID are acceptable here.  The trouble with that is that it
limits you to lower case characters: all the upper case characters are
DISALLOWED.  It could work to say "PVALID characters and their upper
case versions."

But, really, I think Brian's right that we don't need to worry,
especially because there's the designated expert in the middle, who
can say, "PILE OF POO"?  Really?  Why do you want to use that
character?

Barry