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

[Barry Leiba]

> Barry, is there a way to say, "UTF-8 without all the confusing parts"?
> Is that what IDN 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

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Barry Leiba]

>> 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
>
> or perhaps more precisely:
>
> During initialization of nodes there will be a transition period...

Yep; better.

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

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

Makes sense to me.  Carry on.

Barry

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Brian E Carpenter]

On 10/03/2017 05:53, Barry Leiba wrote:
>> > 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.
> 
> 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

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.

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

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

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Barry Leiba]

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

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

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

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

___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Michael Richardson]

Brian E Carpenter  wrote:
>> 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?

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

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

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

> 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 , Sandelman Software Works
 -= IPv6 IoT consulting =-





signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima

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

[Brian E Carpenter]

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

Two points for the WG:

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

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

Personal opinion: encryption should be a MUST.

On UTF-8:

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

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

On 08/03/2017 16:44, Brian E Carpenter wrote:
> 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
>> 

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

[Brian E Carpenter]

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