Subject: [Anima] [Closed] Re: Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09

From: Toerless Eckert <[email-masked]>
Date: Thu, 31 May 2018 03:53:21 +0200

Thanks a lot, BRSKI authors (i think primarily Michael had the pain
of working through my feedback holding the editor pen.)

I have examined the mailing list feedback for all the incremental work
done since -09 including calls we had discussing/resolving several
of the issues. I like most of the work/fixes done towards -14 and
agree or at least accept the rest. Just few tiny bits leftover
(see below). For brevity i am not going to walk through the other
points, but thanks a lot for the discussion replies, especially 
when proving me wrong (;-).

[ Pls. let me know if i overlooked responding to any open issue you
  wanted to get an answer from me to, i hope/think, there is none. ]

I am pretty happy with the BRSKI document now (-15). Obviously the
last versions also had a lot of other important fixes/improvements made,
not only those from the shepherd review.

The authors asserted that the document is ready for WG last call, and i agree.

Cheers
    Toerless

---

> > f) IMPORTANT: Please add/define the term "ANI"
> 
> > ANI - "Autonomic Network Infrastructure". Systems that support both BRSKI and
> > Autonomic Control plane - ACP ([I-D.ietf-anima-autonomic-control-plane]). ANI
> > systems (pledges, proxies, registrar) have specific requirements detailled in
> > the document.
> 
>     <t hangText="ANI:">The Autonomic Network Infrastructure as
>     defined by <xref target="I-D.ietf-anima-autonomic-control-plane"
>     />.  This document details specific requirements for pledges,
>     proxies and registrars when they are part of an ANI.</t>
> 
> Does this work for you?

I would prefer to have the simple definition "ANI == systems that support
both BRSKI and ACP" in the doc itself. Threre is really no single authoritative
normative document for ANI, so it should simply be stated equally in BRSKI and
ACP. Rest of text is fine.

---

> > Without this term we can not nail down the explicit requirements against
> > ANI Pledges, Proxies, Registrars that we need from the document (and distinguish
> > from requirements against any non-ANI adaptation of BRSKI). I added according
> > comments into other parts of the doc.
> 
> > g) Please replace "MASA server" with "MASA service" everywhere.
> 
> I prefer to just say "MASA" actually.
> Are you okay with that?

Yes. There are a few leftovers of "MASA server" in -14 though. Pls fix.

---

> There is no requirement that the Join Registrar is also the EST for the
> purposes of ongoing certificate renewal.  I don't know if you are speaking
> about certificate lifetime management (renewal, etc.) when you say
> "EST Enrollment service".  I'll assume that you mean that for the moment.
> 
> In a big network I would want the roles (bootstrap and initial certificate,
> vs certificate renewal) split up.    

Lets in any case consider this issue closed or BRSKI, because it loooks now like
scope creep to me to discuss it for this draft. I'll probably have this discussion
on my hand for ACP anyhow, because (only) ACP needs to be concerned about
initial bootstrap and renewal (just working through that in ACP doc because
of the ongoing review of it).

---

4.1.1:

> transport-proto  = IPPROTO_TCP / IPPROTO_UDP / IPPROTO_IPV6

The way i see it, the normative approach with TCP circuit proxy would
always only have TCP, right, e.g.: the line should say

transport-proto  = IPPROTO_TCP ; Not considering non-normative
                               ; options like Appendix C.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 31 May 2018 14:45:29 +1200

On 31/05/2018 13:53, Toerless Eckert wrote:
...
>                                ; options like Appendix C.

There's kind of a general point about extensibility here.
We're using CDDL as a normative notation (which may well become
slightly awkward unless the CDDL draft advances soon), but are
we intending to interpret it formally? In other words,
if we later want to add " / IPPROTO_UDP / IPPROTO_IPV6"
to implementations, do we have to circle back and update the BRSKI
RFC? (And so on for any other documents that cite intrinsically
extensible items like transport-proto.)

One option in this case is to include  "/ IPPROTO_UDP / IPPROTO_IPV6"
in the syntax with a specific note that they are not currently
defined and MUST be treated as errors if received.

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 May 2018 15:07:15 -0400

> ACP. Rest of text is fine.

I'm not getting what you are suggesting.
I think you are saying that we shouldn't point at ACP for the ANI term, but
rather define it ourselves?

    > Yes. There are a few leftovers of "MASA server" in -14 though. Pls fix.

fixed them all, I hope.

    > of the ongoing review of it).

okay.

    > ; options like Appendix C.

I'll reply to Brian.

-- 
]               Never tell me the odds!                 | ipv6 mesh networks [ 
]   Michael Richardson, Sandelman Software Works        | network architect  [ 
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 31 May 2018 21:09:10 +0200

Brian:

1. The GRASP specification of 4.1.1 should only describe what is required
and valid for the standard of GRASP objective, which is the TCP proxy.
Appendix C proxy option is not full/formally worked out, thats why
its in an appendix. If the authors want to propose a formal GRASP
option for appendix C proxy, then that should better go into appendix
C as well. Rather a bit more duplicated text then confusing what
objective details are used for what type of proxy.

Therefore only "IPPROTO_TCP" IMHO.

Also nitpick: 
  locator         = [ O_IPv6_LOCATOR, ipv6-address, ..

should be:
  locator-option  = [ O_IPv6_LOCATOR, ipv6-address, ..

(because prior definition of "flood-message" does say "locator-option"]

2. A value of IPPROTO_IPV6 which i guess would be desired for an
appendix C proxy would IMHO be an extension to whats defined in GRASP.
An RFC specifying that would therefore have to declare itself to be
an update of GRASP. I don't think this is a big deal. It would become
somewhat frustrating when we have to figure out multiple extensions
to GRASP header options across multiple future RFCs. But the GRASP
headers are not that complex, so there is not that much to do.
A simple option could be to make a simple rev of GRASP RFC that
accumulates all extensions - after a while, e.g.: after three RFCs
that extend GRASP.

Btw: The specific issue of extening transport options could have been
avoided by permitting 0..255 in GRASP.

Cheers
    Toerless

On Thu, May 31, 2018 at 02:45:29PM +1200, Brian E Carpenter wrote:
> ....
> _______________________________________________
> Anima mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/anima

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 May 2018 15:09:06 -0400

> we intending to interpret it formally?
    
    > In other words,

I don't mind saying that only IPPROTO_TCP is normative in the CDDL,
but I think that the point of listing a few options here is so that
implementations actually check the value.

    > defined and MUST be treated as errors if received.

I prefer this to the not listing them.

---

From: Toerless Eckert <[email-masked]>
Date: Thu, 31 May 2018 21:09:43 +0200

> rather define it ourselves?

Yes.

Thanks
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 May 2018 15:31:26 -0400

> Yes.

okay, I've copied text:

   ANI:  "Autonomic Network Infrastructure".  The ANI is the
         infrastructure to enable Autonomic Networks.  It includes ACP,
         BRSKI and GRASP.  Every Autonomic Network includes the ANI,
         but not every ANI network needs to include autonomic functions
         beyond the ANI (nor intent).  An ANI network without further
         autonomic functions can for example support secure zero touch bootstrap
         and stable connectivity for SDN networks - see
         [I-D.ietf-anima-stable-connectivity]

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

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 May 2018 15:35:31 -0400

> its in an appendix. If the authors want to propose a formal GRASP

It's not mandatory to implement, which is why it got pushed to the appendix.
If it wasn't worked out, then it would be removed.

    > appendix C proxy would IMHO be an extension to whats defined in GRASP.

I think you mean, "defined in the GRASP object defined in CDDL", here.

    > an update of GRASP. I don't think this is a big deal. It would become

I think that you mean, update of BRSKI rather than "update of GRASP".

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Jun 2018 08:23:32 +1200

>          [I-D.ietf-anima-stable-connectivity]

Wrong answer, IMHO.

draft-ietf-anima-reference-model defines the ANI at some length.
That should be the (informative) reference for basic terminology.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 1 Jun 2018 08:40:43 +1200

> I think that you mean, update of BRSKI rather than "update of GRASP".

Possibly both, because GRASP already defines

     transport-proto = IPPROTO_TCP / IPPROTO_UDP
     IPPROTO_TCP = 6
     IPPROTO_UDP = 17

> avoided by permitting 0..255 in GRASP.

Except that it would implicitly lock us into to a particular IANA registry,
allowing strange things like

     transport-proto = IPPROTO_TP

and who's to say that we might not also want things like

     transport-proto = HTTPS

I agree that we might want to revisit this in a GRASP update.

    Brian

---

From: Michael Richardson <[email-masked]>
Date: Thu, 31 May 2018 21:59:48 -0400

> transport-proto = IPPROTO_TCP / IPPROTO_UDP

Ah right.
I just don't care... someone else decide and tell me what.