Subject: [Anima] review of draft-irtf-nmrg-an-gap-analysis-01

From: Rene Struik <[email-masked]>
Date: Tue, 16 Sep 2014 18:42:06 -0400

Dear colleagues:

Please find below my initial comments on 
draft-irtf-nmrg-an-gap-analysis-01.

1. Summary:
The draft discusses some historical context and areas where IP 
networking has moved towards more autonomic/autonomous operations and 
where gaps remain and proposes how to address some of these.

2.General comments:
a) While it is interesting to mention some historical context of 
evolution of approaches towards more autonomy (Sections 3.1-3.4), it is 
unclear how those sections relate to the proposed approach towards 
tackling gaps.
b) Section 4 would benefit from including also some head ache areas in 
security configuration, including OCSP, CRLs, policy pushes, device 
provisioning, etc.
c) Some approaches in Section 5 do not seem to depend on addressing a 
fallacy in providing autonomous operations, but seem more general good 
design principles. As an example, the potential to be able to re-use 
some well-designed components (Section 5.2) is a generally desirable 
feature, where the desired feature list (the bulleted items) mostly 
seems to be about implementing "separation of concerns" (e.g., provide 
core protocol functionality of a configuration scheme, where the data 
elements to be configured are orthogonal to the core scheme). Striving 
for less configuration (Section 5.3) is another example of a general 
desiderata item that does not seem to have too much to do with 
autonomous operation (except to say that one should avoid dependencies 
that are not necessary). Being able to harness network intelligence 
(Section 5.5) is yet another good approach towards improving management 
decisions, but that does not seem too different from stating actually 
using aggregation of information in the network, a well-known concept.
d) Rather than having a negotiation protocol between two devices, one 
might as well use a synchronization protocol instead, where both devices 
synchronize information of mutual interest. If one device does not have 
current info, this automatically could result in pushing the lacking 
info onto the device.

3. Specific comments:

Section 1:
1) In the last sentence of this section, remove "in any case"

Section 2:
2) Why not move the term "automatic" to the "definition document" 
(currently, draft-irtf-nmrg-autonomic-network-definitions-03), so as to 
have terminology all in one place?

Section 3:
3) In Section 3.2, first para, last sentence, replace "big enough" by 
"large enough".
4) In Section 3.5, isn't online authentication through Radius 
"automatic" rather than "autonomic"?
5) In Section 3.5, the online user authentication is in a single trust 
domain. This precludes lot of scenarios where heterogeneity is the norm, 
such as mix-and-match installation/configuration scenarios. As case in 
point of complexities of prevalent approaches (so as to point out that 
most online authentication protocols are not autonomic at all, since 
requiring lots of background infrastructure, secret handshakes, etc.), 
consider the case where a smart phone of user A with provider Verizon 
wishes to connect to an access point B of NTT (e.g., to offload cell 
phone data traffic to an 802.11 pipe). Here, to make authentication 
work, NTT and Verizon need to have a pre-existing business relationship 
and there needs to be a facility to message between Verizon's and NTT's 
server in a timely manner. Apart from technical complexities, this also 
illustrates that one requires infrastructure and business relationships 
in place (thereby, requiring pre-establishment of aligned business 
interests to make this work as well).
6) Section 3.6, p. 6, 2nd para: Replace "For example user" by "For 
example, user"
7) Section 3.6, p. 6: I would prefer untangling of lots of the nmrg 
drafts, which now often cross-reference each other (I had to read them 
all, due to have "self-citation"-- well, on the author level). Having 
all this cross-referencing makes it hard to evaluate a draft on its own 
merits and to see whether certain designs all have to be used 
simultaneously or not at all, or whether these cover modules that are 
largely independent. I would suggest removing the last two sentences of 
this section (i.e., remove "A proposal... central policy" entirely").
8) Section 3.6, p. 6: I do not understand what the draft on 
opportunistic security has to do with autonomic networking (except to 
use crypto mechanics to provide unspecific benefits). Please remove.
9) Section 3.7: While the last sentence ("Even one undefined parameter 
would be sufficient to prevent fully autonomic operation") is 
technically correct, this suggests that this is always a bad thing. I am 
concerned with any all or nothing thinking here, since one has to strike 
the right balance between centralized configuration and management and 
putting all intelligence into devices, with no decision input by 
non-local processes, which balance is hardly ever black and white, but 
most of the time a grey scale. "Everything should be made as simple as 
possible, but not simpler".

Section 4:
10) first sentence: replace "In the current" by "in current".
11) first sentence: replace "depending" by "dependent".
12) last para: replace "the current" by "typical current".
13) Section 4.1, first para: some of the complexities of "user 
authentication and accounting policies" are caused the perception that 
these should all be centralized, with an operator in the middle of each 
authentication transaction.
14) Section 4.1, 2nd para: replace "forseeable" by "foreseeable". (Also 
elsewhere.)
15) Section 4.2: I wonder how remote synch functionality and apps change 
the picture portrayed here ("currently, the end users have to manually 
manage their user accounts and authentication information when they 
switch among networks or network services"). Is this still true in a 
brave new world with Boingo, Google Synch, etc., password managers, etc.?
16) Section 4.3, last para (p. 9): replace "routing round" by "routing 
around" (line -5).

Section 5:
17) Section 5.2, bulleted list: the fourth bullet ("little 
dependency...") does not align with the pre-amble of the list ("should 
be ...").
18) Section 5.3, third line: "operationse" should read "operations".
19) Section 5.3, 2nd para: "resulst" should read "results".
20) Section 5.3: I would add some verbiage about profiles (strangely, 
not mentioned right now), since those could help in cutting down on 
configuration complexities.
21) Section 5.4, last sentence (p. 11): replace "effect" by "impact"

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 17 Sep 2014 11:20:11 +1200

Thanks, Rene, for your two detailed reviews. It will take the
various authors a while to digest them, but I do appreciate such
reviews even if they create a certain amount of work.

I'm not sure whether to respond in detail here or on the NMRG list.

Regards
   Brian

> draft-irtf-nmrg-an-gap-analysis-01.

<snip>

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Wed, 17 Sep 2014 15:29:51 +0000

> -----Original Message-----
> From: Anima [mailto:[email-masked]] On Behalf Of Brian E
> Carpenter
> Sent: 17 September 2014 01:20
> To: Rene Struik
> Cc: [email-masked]
> Subject: Re: [Anima] review of draft-irtf-nmrg-an-gap-analysis-01
> 
> Thanks, Rene, for your two detailed reviews. It will take the various authors
> a while to digest them, but I do appreciate such reviews even if they create
> a certain amount of work.

I second Brian. It'll make the docs better. Thanks for  the feedback! 
 
> I'm not sure whether to respond in detail here or on the NMRG list.

This is a recurring question. I suggest we stick to the "correct" group: For the nmrg drafts, we discuss on nmrg, and for the anima work on anima. Anything else is hard to understand or results in lots of cross posting. I think the two domains are now more or less clearly separated. 

Thoughts? 
Michael
 
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 23 Sep 2014 14:48:47 +1200

Rene,

> draft-irtf-nmrg-an-gap-analysis-01.

...
> security configuration, including OCSP, CRLs, policy pushes, device

Can you sketch this in a bit more detail? I'm having a little
difficulty because I'm not sure how the examples you give
can be turned into self-management. In particular a lot of
this is top-down, isn't it? Or do you think CRLS can be
generated down in the infrstructure?

Regards
    Brian

---

From: "Michael Behringer (mbehring)" <[email-masked]>
Date: Fri, 26 Sep 2014 14:10:37 +0000

> Sent: 23 September 2014 04:49
> To: Rene Struik
> Cc: [email-masked]
> Can you sketch this in a bit more detail? I'm having a little difficulty because
> I'm not sure how the examples you give can be turned into self-
> management. In particular a lot of this is top-down, isn't it? Or do you think
> CRLS can be generated down in the infrstructure?

I think I understand what Rene meant, and gave this a shot. See below a new security section for pre-view and comments. This text isn't only my work, it came from Brian and Sheng as well. 

So the below would go into section 4: Rene, does this address your points? 

Michael

<section title="Security Setup">
        <t>Setting up security for a network generally requires very detailed
        human intervention, or relies entirely on default configurations that
        may be too strict or too risky for the particular situation of the
        network. While some aspects of security are intrinsically top-down
        in nature (e.g. broadcasting a specific security policy to all
        hosts), others could be self-managed within the network.  </t>
        <t>
        In an autonomic network, where nodes within a domain have a mutually
        verifiable domain identity, security processes could run entirely
        automatically. Nodes could identify each other securely, negotiating
        required security settings and even shared keys if needed. The location 
        of trust anchors (certificate authority, registration authority),  
        certificate revocation lists, policy server, etc can be 
        found by service discovery. Transaction such as a certificate revocation 
        list download can be authenticated via a common trust anchor.  
        Policy distribution can also be entirely automated, and secured via 
        a common trust anchor. </t>
        <t>These concepts lead to a network where the intrinsic security is 
        automatic and applied by default, i.e., a "self-protecting" network. 
        see also <xref target="I.D-behringer-default-secure"/></t>
      </section>

---

From: Dean Bogdanovic <[email-masked]>
Date: Tue, 30 Sep 2014 21:33:35 +0000

On Sep 26, 2014, at 10:10 AM, Michael Behringer (mbehring) <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: Anima [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Brian E
Carpenter
Sent: 23 September 2014 04:49
To: Rene Struik
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [Anima] review of draft-irtf-nmrg-an-gap-analysis-01

Rene,

...

Michael

       automatically.
You meant here automatically or autonomic?

Nodes could identify each other securely, negotiating

Regards
   Brian

_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima

_______________________________________________
Anima mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/anima