Subject: Re: [Anima] I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt

From: Toerless Eckert <[email-masked]>
Date: Mon, 18 Sep 2017 08:04:29 +0200

On Wed, Aug 02, 2017 at 02:39:03PM +1200, Brian E Carpenter wrote:
> Hi,
> 
> Here are my comments on ACP version -08. First the ones I rank
> as substantive isssues, then a few nits.

Thanks so much Brian, lots of help to improve quality.

Alas, i got derailed from finishing the fixes for your review because the
reviews/last-call for stable connectivity which had me figure out a bunch of
changes to ACP document, and i first put all of those in acp-09 (and then i
had a bunch of business travel, so i thin i hadn't even sent out a note
about -09 to the list).

Changes -08 - 09:

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-08.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-09.txt

Might be useful to check that diff out separately, key big blocks:

- Made the V8 scheme more flexible (allow 16 bit addresses, eg: for the
  the stateless BRSKI proxy mechanisms you and MichaelR where discussing.
- All RPL profile detail fixups from MichaelR's review
- Expanded ACP connect section (taken over from stable-connectivity).
- introduced manual addressing sub-scheme for more consistent autonomic-connect
  (also as outcome of stable-connectivity review)
- Doc now claims to update RFC4291/RFC4193, section to summarize
  those updates - aka: that section is meant for later review by 6ops or 6man.

Details of changes of course in changelog of the draft.

The changes from your review below then got into acp -10 that i just posted:

Changes -09 - 10:

http://tools.ietf.org/tools/rfcdiff/rfcdiff.pyht?url1=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-09.txt&url2=https://tools.ietf.org/id/draft-ietf-anima-autonomic-control-plane-10.txt

See below. Hopefully all answers to your points are satisfactory.

Cheers
   Toerless

> Issues:
> -------
> 
> > 2.  Terminology
> ...
> > ULA  "Unique Local Address".  The IPv6 equivalent to RFC1918 IPv4
> > addresses.  ACP addresses are ULA.
> 
> No, they are *not* equivalent to RFC1918, because those are ambiguous
> and ULAs are not. Please avoid controversy, just cite RFC4193.

IMHO, a terminology section has to try to explain terms without making the reader refer to ever mor ereferences.  Had a lot of customers who didn't know what ULA are, but who klicked when
i mentioned 1918. And differences/benefits over 1918 become obvious later in doc anyhow (ambiguity).

acp-10 text:

   A "Unique Local Address" (ULA) is an IPv6 address in the block fc00::/7, defined in 
   <xref target="RFC4193"/>. It is the approximate IPv6 counterpart of the IPv4 private address 
   (<xref target="RFC1918"/>).

If you do not like that, please fix in Wikipedia wherer i stole this from:
    https://en.wikipedia.org/wiki/Unique_local_address
;-)

> > 3.2.  Secure Bootstrap over an Unconfigured Network
> ...
> > ...This does not require any configuration
> > on intermediate nodes, because they can communicate through the ACP.
> 
> s/they can communicate/they can communicate securely/

ACK

> > 4.  Requirements
> ...
> > ACP4:  The ACP MUST be generic.  Usable by all the functions and
> >        protocols of the AN infrastructure.  It MUST NOT be tied to a
> >        particular protocol.
> 
> I'm not sure what the last sentence is saying. Do you mean
> "MUST NOT be tied to a particular transport protocol" or
> "MUST NOT be tied to a particular security protocol"?
> Or do you mean "MUST NOT restrict the choice of upper layer
> protocol"? Or do you simply mean "MUST provide a generic
> IPv6 service"?

This goes back to very early discussions in ANIMA when we argued that
a greenfield autonomic networking design would not need any protocol other
than GRASP for any ASA to ASA communications. In which case there would
not have been a good argument for ACPs concept of a virtual IPv6 network
to transport any management traffic. 

acp-10: "NOT be tied to a particular application or transport protocol.".

Please suggest better text if thats not sufficient.

> Also, there's no requirement about performance or the
> expected traffic density. Should we say something either
> in the Requirements section or in the Notes in the
> Overview section? I assume that performance is not critical
> and ACP traffic density is expected to be low.

My practical experience was that proliferation of implementation was
easier when you did not have performance requirements but when you could
implement also in just software forwarding path. This did then lead
to text in stable connectivity arguing about using the ACP primarily
for critical operations. 

acp-10 has a new performance section restate that position:

                            <section anchor="performance" title="Performance">
<t>There are no performance requirements against ACP implementations defined in this document because the performance requirements depend on the intended use case. It is expected that full autonomic devices with a wide range of ASA can require high forwarding plane performance in the ACP, for example for telemetry, but that determination is for future work. Implementations of ACP to solely support traditional/SDN style use cases can benefit from ACP at lower performance, especially if the ACP is used only for critical operations, eg: when the data plane is not available. See <xref target="I-D.ietf-anima-stable-connectivity"> for more details.</t>
                            </section>

Pls. suggest better text if you feel this is insufficient/inadequate.

> > 5.  Overview
> ...
> >   Default policy is: To all adjacent nodes in the
> >   same domain.
> 
> I know this is explained later, but I think both
> "adjacent" and "domain" need some qualification.
> For example:
> 
>   Default policy is: To all adjacent link-layer autonomic
>   nodes in the same autonomic domain.

I am daring to claim this is better english:

acp-10: To all link-layer adjacent autonomic nodes in the same autonomic domain.

> >    5.  Inside the ACP VRF, each node sets up a virtual (loopback)
> >        interface with its ULA IPv6 address.
> 
> I think we have cases where a node has multiple ULAs.

Right now, an ACP would have exacty one Certificate derived ULA
and 0 or more configured ones for autonomic-connect interfaces in case
the operator wants to use the manual addressing sub-scheme on the autonomic
connect interface.

What other cases are you thinking of ?

> > 6.1.  Domain Certificate
> > 
> >    To establish an ACP securely, an ACP device MUST have a globally
> >    unique domain certificate (LDevID),...
> 
> You need a normative reference for the LDevID format.

acp-10: Added 802.1AR reference and pointed to it in terminology section for IDevID and LDevID.

> > 6.1.1.  ACP information
> > 
> >    The domain certificate (LDevID) of an autonomic node MUST contain ACP
> >    specific information, specifically the domain name, the address of
> >    the device in the ACP with the Zone-ID set to zero ("ACP address").
> 
> You need a cross-reference for Zone-ID, which is undefined at this point.

acp-10: Removed the zone-ID details here and explained it only in the description of the sub-schemes
More logical now that there are multiple address sub-schemes (only one of them with a zone field).

> ...
> >    anima.acp+<acp-address>{+<rsub>{+<extensions>}}@<domain>
> 
> What notation is that? Is {} supposed to be an optional item?
> If so, why not use [] as in ABNF, and cite ABNF.

acp-10: Done. Please check again. Got a lot more complex by using ABNF, but maybe more precise.

> >  <domain> is used to indicate...
> 
> Is that required to respect DNS syntax? If so, please say so.

Yes. That was already in -09.

> > {<rsub>.}<domain>
> 
> That's wrong. <domain> is preceded by "@" in your syntax, and 
> in your example, the dot is in the <extensions> element
> "area51.research".
>
No, it was correct, but hopefully now with ABNF and the explicit example expanded it's
less easy to misread, although i am not 100% sure that ABNF really allows me to
specify what i want 100%:
  
 [email-masked]

 routing-subdomain = area51.research.acp.example.com
                                    ^
                                    |
This dot needs to come from the syntax because it is not in the actual ACP information
string, it is the connector between the rsub part and the acp-domain.

In ABNF the problem is that i need the option to specify the rsub part as optional,
but then i want to say that this connecting dot is also only used when the rsub part is
empty. And i think there is no ABNF element to do this. Check the ABNF i have written,
i am rying to wing that problem. ...

> Is there a length limit on the rfc822Name ?

Seemingly yes, but difficult to hunt down.

I have written now:

Note that the maximum size of "acp-information" is 254 characters and the maximum size of acp-device-info is 64 characters according to <xref target="RFC5280"> that is referring to <xref target="RFC2821"> (superceeded by <xref target="RFC5321").

So yes... not much extension space if any (depending on how long you want/need to do rsub and how long your domain is). But we could use multiple rfc822 addresses in the same certificate to encode other things when we need to.

> > 6.1.2.  Maintenance
> 
> a) As Michael R said,
> b) all the stuff about the registrar should be in BRSKI, not duplicated here.
> c) In fact, it's > very confusing to have it here.
> d) If we want a cert renewal mechanism, surely that's part of BRSKI?

b), c) BRSKI only specifies zero touch bootstrap, but not certificate maintenance/renewal.

ACP should be modular, eg: we should be able to combine it with any initial bootstrap
(BRSKI of course preferred and only BRSKI+ANIMA+GRASP = ANI, but netconf-zero-touch or
other would be possible option if so desired). So we need zero-touch certificate
(renewal, revocation) specification in ACP doc.

Cert renewal in ACP spec is using EST (RFC7030). Use of GRASP is specified in ACP draft
is solely to support this EST renewal. Without GRASP to find EST-Server, we can not
support EST-Server redundancy: YOu can specify a URL for reneal in the certificate,
but if that URL goes down, you're lost. Without ACP/GRASP you would have had to setup some
form of anycast domain-name or ip-address in the URL - or worse yet list multiple registrar.

The GRASP objective in BRSKI is BRSKI-TLS and is discovered by bootstrap proxies, the
GRASP objective in ACP is EST-TLS and is discovered by encrolled ACP members for their
own Cert renewal. Big difference.

c) Initially i thought too that RSKI would be a superset of everything that we'd need
for certificate maintenance, but thats not the goal of BRSKI. It is only meant o specify
initial bootstrap, but not cert renewal or the like.

a) I think to remember that MichaelR was pretty positive on the mike in Prague about
the inclusion of EST in ACP spec for renewal. But i am sure he will chime in. 

The confusing bits may be how to use GRASP. Here is what current ACP and BRSKI text
would lead to:

- ACP registrar without BRSKI: registrar == EST-server
  registrar announces AN_join_registrar with only EST-TLS objective value

- ACP registrar with BRSKI: registrar == EST-server + BRSKI spec
  registrar announces AN_join_registrar with both EST-TLS and EST-BRSKI objective values

> >    The loop-count MUST be sete to 255.  When an ACP node
> >    receives the M_FLOOD, it will have been reduced by the number of hops
> >    from the EST server.
> 
> I don't like that. The role of the loop count is loop prevention,
> so it should be set to a reasonable upper bound on the "radius"
> of the network. GRASP has two measures for loop detection, this
> one and detection of duplicate session IDs, but that was
> intentional redundancy.]

Sure, and if we set loop-count to a well-known value such as 255 then
we do use it in the same way as IP uses TTL: Just as a way of last defense.
Primary method is loop-free routing protocols (IP) or duplicate session ID (GRASP).

[50% rant:]
Every new technology seems to think that TTL is a great tool, only then to
figure out later that its only a good protection of last resort. IP unicast
did this, and today, nobody really uses any TTL other than 255 or 1.
IP multicast regurgitated TTL values for "TTL scoping" and it took almost
10 years to get rid of it, we depreciated that, and since ~2000 IP multicast
also only uses 255 or 1 since then. IMHO: Same learning curve is necessary for GRASP.
Maybe we will come up with good use cases for 1 < TTL < 255 still, but i doubt
it. Unless you have very specific variations of eg: ACP for networks with
well-knon smaller max-TTL, i do not see it.
[/rant]

But you do not need to buy into this logic of mine. I just want to put you in the
bind for an ability in GRASP to discover the closest instance of an objective.
Thats i think something you agreed GRASP will support a long time ago.

If you do not like to use the fixed TTL value of 255 as a mechanism to help
support the "closest objective announcer" mechanism, then i need to specify
a more complex way to discover the closest objective announcer:

- objective-values for AN_join_registrar would need to be extended to be a structure like:

  objective-value = [ sender-ttl, method-list [, future-extensions]* ]
  method-list = [ method ]*1
  methd = BRSKI-TLS | EST-TLS | ...
  sender-ttl = NUM

  (pretty sure i didn't get the CBOR template not right, but i am sure you get the idea)

That way, the recipient can compare sender-ttl with the TTL of the received objective
and threeby figue out which one is closest.

I fine either way. I just tried to go for the most simple, logical option.

> > 6.2.  AN Adjacency Table
> > 
> >    To know to which nodes to establish an ACP channel, every autonomic
> >    node maintains an adjacency table.  The adjacency table contains
> >    information about adjacent autonomic nodes, at a minimum: node-ID, IP
> >    address, domain, certificate.
> 
> Please specify which IP address(es) you mean. Link-Local, ACP
> Address(es), or both?

acp-10: Added.  Its the link local.

It was described further below in the doc already:

<t>The result of the discovery is the IPv6 link-local address of the neighbor as well as its supported secure channel protocols (and non-standard port they are running on).  It is stored in the AN Adjacency Table, see <xref target="adj-table" /> which then drives the further building of the ACP to that neighbor.</t>

> Can you also indicate that an API to this table is needed (at 
> least by the GRASP core, and possibly by any ASA that wants to
> make direct use of the ACP)?

acp-10:

<t>Interaction between ACP and other autonomic elements like GRASP (see below) or ASAs
should be via an API that allows (appropriately access controlled) read/write access to the AN Adjacency Table. Specification of such an API is subject to future work.</t>

> > 6.3.  Neighbor Discovery with DULL GRASP
> ...
> >           [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 1,
> >               ["AN_ACP", SYNCH-FLAG, 1, "IKEv2"],
> >               [O_IPv6_LOCATOR,
> >                    h'fe80000000000000c0011001FEEF0000, UDP, 15000]
> >           ]
> 
> Once we are fully settled on this I can generate an example and
> its binary value for complete clarity. I have one comment which is
> that when I last updated draft-carpenter-anima-ani-objectives,
> I replaced "SYNCH-FLAG" with "5" (the actual value of the flag
> byte) - otherwise you have to define SYNCH-FLAG. Actually
> the value 5 indicates discovery+synchronization; everything
> should work just the same if it was 4 (synchronization alone),
> since it's flooded. I don't know if we care about that difference.

acp-10: defined sync-only and used that for both grasp ojectives.

> >    The ttl and loop-count are fixed at 1 since this is a link-local
> >    operation.
> 
> No, the ttl is milliseconds - the valid lifetime of the flood.
> You have that correct in your version of AN_join_registrar.

acp-10: Fixed.

> > 6.8.2.  ACP as the Security and Transport substrate for GRASP
> ...
> >    GRASP inside the ACP uses link-local UDP IPv6 multicast across the
> >    ACP virtual interfaces for GRASP neighbor discovery...
> 
> and flooding

acp-10: Ack.

> Also, you might want to add a reminder that GRASP does its own
> relaying of multicast packets between interfaces; the ACP is
> not required to provide multicast routing.

Saying that was actually the intent of the prior section "GRASP as a core service of the ACP"
But maye sentence was not good.

acp-10:  Please check 6.8.1 again. There is now a rather comprehensive description of
GRASP, IP multicast, flooding and so on. Too long to paste here unfortunately. Maybe
some of the later paragraphs can go into an appendix. But given how this IMHO abuse
of IP multicast to do service discovery is still going on since 30 years no, i do
appreciate any opportunity to write down a sane option ;-)

> >                                                  ...and IPv6 over TLS
> >    across the ACP virtual interfaces for any of its unicast messages.
> 
> Wait, what are you saying here? Do you really mean IPv6
> over TLS, or TLS over TCP over IPv6?

Oops, that was just a bad ordering of words. The intention even in -08 was to have
GRASP always be carried "natively" (without any UDP/IP packet headers) inside 
TLS/TCP (for "unicast" connections) or just via TCP (for connections to ACP neighbors on
their link-local addresses - TLS not required here because it doesn't add anything
on top of the ACP secure channel mechanism in this case).

Pls. re-check 6.8.2 i overhauled it.

> As Eric Rescorla asked us at one point, please draw a ladder
> diagram of the protocol stack.

This is now part of 6.8.2:

         ACP:
    ...............................................................
    .                                                             .
    .         /-GRASP-flooding-\         ACP GRASP instance       .
    .        /                  \                                 .
    .    GRASP      GRASP      GRASP                              .
    .  link-local   unicast  link-local                           .
    .   multicast  messages   multicast                           .
    .   messages      |       messages                            .
    .      |          |          |                                .
    ...............................................................
    .      v          v          v    ACP security and transport  .
    .      |          |          |    substrate for GRASP         .
    .      |          |          |                                .
    .      |       ACP GRASP     |       - ACP GRASP loopback     .
    .      |       loopback      |         loopback interface     .
    .      |         TLS         |       - AN-cert auth           .
    .      |          |          |                                .
    .   ACP GRASP     |       ACP GRASP  - ACP GRASP virtual      .
    .   subnet1       |       subnet2      virtual inerfaces      .
    .     TCP         |         TCP                               .
    .      |          |          |                                .
    ...............................................................
    .      |          |          |   ^^^ Users of ACP (GRASP/ASA) .
    .      |          |          |   ACP interfaces/addressing    .
    .      |          |          |                                .
    .      |          |          |                                .
    .      |      ACP-loopack    |       - ACP loopback interface .
    .      |      ACP-address    |       - address (global ULA)   .
    .    subnet1      |        subnet2   - ACP virtual interfaces .
    .  link-local     |      link-local  - addresses              .
    ...............................................................
    .      |          |          |   ACP routing and forwarding   .
    .      |     RPL-routing     |                                .
    .      |   /IP-Forwarding\   |                                .
    .      |  /               \  |                                .
    .  ACP IPv6 packets   ACP IPv6 packets                        .
    .      |/                   \|                                .
    .    IPsec/dTLS        IPsec/dTLS  - AN-cert auth             .
    ...............................................................
             |                   |   Data Plane
             |                   |     
             |                   |     - ACP secure channe
         link-local        link-local  - encap addresses
           subnet1            subnet2  - data plane interfaces
             |                   |
          ACP-Nbr1            ACP-Nbr2

> ...
> >    TLS is mandated for GRASP because the ACP secure channel mandatory
> >    authentication and encryption protects only against attacks from the
> >    outside but not against attacks from the inside - compromised ACP
> >    members
> 
> I think the threat model really needs a clearer explanation. I assume
> that Bob and Alice are good guys, and Eve is a malicious ACP member.
> So a packet from Alice to Bob is encrypted from Alice to Eve, decrypted
> by Eve, then encrypted from Eve to Bob. So Eve can do what she wants
> with the decrypted packet.

I've only been using https://en.wikipedia.org/wiki/Alice_and_Bob
where it was easy enough, but not when discussing attacks against GRASP/ACP
I think its easier to memorize the cast of character from Hamlet first than
that rocky horror picture show ensemble.

Eve seems to be only allowed to do passive attacks (Eve(dropper).
If Eve was an ACP member onpath between Alice and Bob, it could observe
the GRASP TCP connection. Assuming Alice and Bob are not only ACP
members but also members of the privacy-advocacy team, they would
always demand end-to-end encryption against Eve. Thats why ACP now
provides TLS connections to GRASP for that purpose.

What i did explain in 6.8.2 is that Mallory, who is permitted to be
an active attacker could be an ACP member and now when Alice tries
to find an objective from Bob, Mallory intercepts the objecive
discovery (whether it's M_FLOOD or M_DISCOVERY), and makes itself
look like Bobs objecctive to Alice, and then once it has captured
the GRASP unicast connection from Alice, it will open another
unicast connection to Bob and now it proxies the unicast GRASP
negotiation between Alice and Bob - so TLs does not help at all.

Check out if you think 6.8.2 is sufficient now, if not maybe propose
more specific text.  9.2.2 is also summarizing the attack vector.

> Now, who does the TLS wrapping? Will that be done by the ACP,
> or by the GRASP core? If the latter, you still need to explain
> how the ACP conveys the cert information to GRASP.

Should be obvious from 6.8.2 now i hope: the ACP GRASP loopback/
virtual interfaces are interfaces that take GRASP messages, so
ACP does the TCP/TLS encap/decap.

> > 6.10.1.  Fundamental Concepts of Autonomic Addressing
> ...
> >    o  Addresses in the ACP are permanent, and do not support temporary
> >       addresses as defined in [RFC4941].
> 
> Add something like:
> 
>   o  Addresses in the ACP are not considered sensitive on
>      privacy grounds, so do not need to be pseudo-random
>      as discussed in [RFC7721].
> 
> (You probably also need to discuss why the ACP is not subject
> to scanning attacks: because ULAs are not propagated across
> domain boundaries.)

acp-10:
<t>Addresses in the ACP are not considered sensitive on privacy grounds, so do not need to be pseudo-random as discussed in <xref target="RFC7721"/> Because they are not propagated to untrusted (non ACP) devices and stay within a domain, we also consider them not to be subject to scanning attacks.</t>.

> 
> > 6.10.2.  The ACP Addressing Base Scheme
> > 
> >    The Base ULA addressing scheme for autonomic nodes has the following
> >    format:
> > 
> >   8      40             2                     78
> > +--+-----------------+------+------------------------------------------+
> > |FD| hash(subdomain) | Type |             (sub-scheme)                 |
> > +--+-----------------+------+------------------------------------------+
> > 
> >                    Figure 2: ACP Addressing Base Scheme
> > 
> >    The first 48 bits follow the ULA scheme, as defined in [RFC4193], to
> >    which a type field is added:
> > 
> >    o  "FD" identifies a locally defined ULA address.
> 
> For the Nth time, please s/FD/fd/ as required by RFC5952

Fixed. Day 1 bug.

Although we can not really use 5952 in the acp-information field, but i like consistency too.

> >    o  Type: This field allows different address sub-schemes in the
> >       future.  The goal is to start with a single sub-schemes, but to
> >       allow for extensions later if and when required.  This addresses
> >       the "upgradability" requirement.  Assignment of types for this
> >       field should be maintained by IANA.
> 
> You need to write precise directions to IANA.

acp-10: Done.  It's just the addressing Type field for now, but could become more.

> > 6.10.3.  ACP Zone Addressing Sub-Scheme
> > 
> >    The sub-scheme defined here is defined by the Type value 0 (zero) in
> >    the base scheme.
> > 
> >            51            1     13                    63             1
> >  +---------------------+---+---------+-----------------------------+---+
> >  |    (base scheme)    | Z | Zone-ID |         Device-ID           | V |
> >  |                     |   |         | Registrar-ID | Device-Number|   |
> >  +---------------------+---+---------+--------------+--------------+---+
> >                                              48           15
> 
> s/51/50/

Thanks.

> Although I think it would be simpler to do this:
> 
>            48        2   1     13                    63             1
>  +----------------+----+---+---------+-----------------------------+---+
>  | ULA prefix     |Type| Z | Zone-ID |         Device-ID           | V |
>  |                | 00 |   |         | Registrar-ID | Device-Number|   |
>  +----------------+----+---+---------+--------------+--------------+---+
>                                              48           15

Not changed:

MichaelM came up with the picture, so i didn't want to change it too much.

Besides, i did run into a benefit of this approach: i changed the
hash(subdomain) to hash(routing-subdomain) because thats the correct term
now, and e voila: i did not have to do this change in the now 3 sub schema pictures.

(its 3 sub schemes now because in -09 i did introduce the manual addressing 
 sub-scheme as well after the "stable-connectivity" review and its resulting
  options for addressing - aka: the safe bet when the 6man police does not like to use
 the Vlong addressing scheme on autonomic connect interfaces).

> > 
> > 6.10.4.  ACP V8 Addressing Sub-Scheme
> > 
> >    The sub-scheme defined here is defined by the Type value 1 (one) in
> >    the base scheme.
> > 
> >              51                           63                 8
> >    +---------------------+-----------------------------+----------+
> >    |    (base scheme)    |         Device-ID           |        V |
> >    |                     | Registrar-ID | Device-Number|          |
> >    +---------------------+--------------+--------------+----------+
> >                                46             32
> 
> Same comments.

see above

> > 6.10.5.  Other ACP Addressing Sub-Schemes
> > 
> >    Other ACP addressing sub-schemes can be defined if and when required.
> >    IANA would need to assign a new "type" for each new addressing sub-
> >    scheme.  With the current allocations, 5 more schemes are possible
> 
> That's confusing. In your terminology, only two more types are
> possible (10 and 11).

Right. Fixed.

> It would be simpler to simply define 3 type bits.

The main constraint is that the original (zone scheme) tried to comply to the
IPv6 address architecture by using a 64 bit interface identifier part. The
same is now true of the manual addressing scheme that i added and i would like
to keep it that way (to be on the safe side with IETF architectures).

MichaelB came up with the zone address scheme and i already stole one bit from
the zone-field to enable the manual addressing sub-scheme because i wanted
to make sure that deployments can get started with using manual configured
ACP connect interfaces without conflicting with later automatic assigned zones.

I am quite unsure how important zones are. I do very much like the Vlong (was
called V8 in -08) scheme because it allows a lot of internal address assignment
within a node, which i think is more important for future work than Zones. But Vlong
does not comply to the 64-bit interface identifier rule.

If you want 3 type bits, we need to go to 12 subnet bits in the zone scheme
and maybe 32/16 Device-ID in the Vlong scheme. I also would feel safer if we
had more Type field options to explore/experiment, but i would like for
more ANIMA participants to chime in.

> A general remark: when a wider audience looks at this, there will
> be complaints that we are re-creating classful addressing. I suggest
> adding some text about this. (Along the lines of: it's true, and
> here is why it doesn't matter.)

I will certainl not mention that word in the document. Its like the courtroom:
I do not want to open the door to that type of accusation by bringing up the word
 myself first ;-)

Here is the paragraph i added at the beginning of 6.10.6 (other ACP addressing
sub schemes):

<t>Before further addressing sub-schemes are defined, experience with the schemes defined here should be collected. The schemes defined in this document have been devised to allow hopefully sufficiently flexible setup of ACPs for a variety of situation. These reasons also lead to the fairly liberal use of address space: The Zone addressing sub-schemes is intended to enable optimized routing in large networks by reserving bits for zones. The Vlong addressing sub-scheme enables the allocation of 8/16 bit of addresses inside individual ACP nodes. Both address spaces allow distributed, uncoordinated allocation of node addresses by reserving bits for the Registrar-ID field in the address.</t>

> >    Every ACP device (RPL node) announces an IPv7 prefix
> 
> Forward into the future!

;-)

> > 6.12.4.  ACP interfaces
> ...
> >    These packets are of course redundant (unnecessary) and would be
> >    discarded by GRASP on receipt as duplicates.
> 
> ...by use of the GRASP Session ID.

ack.

> > 7.2.  How (per L2 port DULL GRASP)
> ...
> > L3/L2 devices SHOULD support per-L2 port ACP.
> 
> Clarify that ACP (and GRASP) capable devices do
> not need to depend on MLD snooping, since they
> catch LL multicasts directly per port. But non-ACP
> switches MUST either support MLDv2 snooping or
> operate as pure L2 bridges for all multicast
> packets.

acp-10, added to 6.3:

    <t>Note that the use of the IPv6 link-local multicast address (ALL_GRASP_NEIGHBORS) implies
    the need to use MLD (<xref target="RFC3810"\>) to announce the desire to receive packets for
    that address. Otherwise DULL GRASP could fail to operate correctly in the presence of
    MLD snooping, non-ACP enabled L2 switches - because those would stop forwarding DULL GRASP
    packets. Switches not supporting MLD snooping simply need to operate as pure L2 bridges for
    IPv6 multicast packets for DULL GRASP to work.</t>
    
Its a common oversight of pretty much every protocol RFC i know thats using link-local scope multicast to NOT mention the need to use IGMP/MLD. In IPv4 it was unclear whether it was necessary to do this for link-local scope addresses and in result, no sane IGMP snooping switch would ever try to constrain link-local messages. I am 100% sure we did make it mandatory in IPv6 to announce membership for link-local addresses, even though i can not find a line in RFC3810 to that end right now. Anyhow, better be safe than sorry (should have gone into GRASP RFC though, oh well.. too late).

For 7.2 i added:

    <t>If the device with L2 ports is supporting per L2 port ACP DULL GRASP as well as MLD snooping
    (<xref target="RFC4541"/>), then MLD snooping must be changed to never forward packets for
    ALL_GRASP_NEIGHBORS because that would cause the problem that per L2 port ACP DULL GRASP
    is meant to overcome (forwarding DULL GRASP packets across L2 ports).</t>

> Also, is there anything to say here about VLANs?

Nothing special comes to mind...
Not that i'd be trying hard ;-)

> > 11.  Security Considerations
> 
> I think you need to insert cross-references to
> various security discussions elswhere in the draft.

Ok. Probably not complete, but i added 6 hopefully good paragraphs with pointers to make security reviewers happy. 
> > 12.  IANA Considerations
> TBD!

Yes, from above.

> Nits:
> -----
> 
> > 2.  Terminology
> ...
> >    ACP VRF  The ACP is modelled in this document as a "Virtual Routing
> >       and Forwarding" (VRF) component in a network device.
> 
> I suggest listing this alphabetically as VRF, not under A.

ack

> >    AN "Autonomic Network".  A network according to
> >       [I-D.ietf-anima-reference-model].  Its main components are Intent,
> >       Autonomic Functions and ANI.
> 
> I find the second sentence doesn't help, especially by referring to Intent.

Any better idea ?

Right now i just added a definition for Intent:

           <t hangText="Intent">Northbound operator and automation facing interface of an Autonomic Network according to <xref target="I-D.ietf-anima-reference-model"/>.

For me it's important that readers of the ACP document know the simple distinction
between ANI and AN:

 AN = ANI + autonomic-functions + intent.

That makes it difficult not to mention intent.

Of course, anything related to intent is fuzzy, but thats an IETF ANIMA charter issue ;-)

>   ** The document seems to lack a both a reference to RFC 2119 and the
>      recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
>      keywords. 
> 
>   == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
>      or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
>      use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
>      mean).

Ok, i just stole the boilerplate from GRASP.

> Regards
>    Brian
============ original mail from Brian appended ===============================

>From [email-masked]  Wed Aug  2 04:39:14 2017
Subject: Re: I-D Action: draft-ietf-anima-autonomic-control-plane-08.txt
To: [email-masked]
From: Brian E Carpenter <[email-masked]>
Organization: University of Auckland
Cc: [email-masked]
Date: Wed, 2 Aug 2017 14:39:03 +1200
Resent-From: <[email-masked]>
Resent-To: [email-masked], [email-masked], [email-masked]
Resent-Message-Id: <[email-masked]>
Resent-Date: Tue,  1 Aug 2017 19:39:10 -0700 (PDT)
Status: RO
Content-Length: 12076
Lines: 342

Hi,

Here are my comments on ACP version -08. First the ones I rank
as substantive isssues, then a few nits.

Issues:
-------

> 2.  Terminology
...
> ULA  "Unique Local Address".  The IPv6 equivalent to RFC1918 IPv4
> addresses.  ACP addresses are ULA.

No, they are *not* equivalent to RFC1918, because those are ambiguous
and ULAs are not. Please avoid controversy, just cite RFC4193.

> 3.2.  Secure Bootstrap over an Unconfigured Network
...
> ...This does not require any configuration
> on intermediate nodes, because they can communicate through the ACP.

s/they can communicate/they can communicate securely/

> 4.  Requirements
...
> ACP4:  The ACP MUST be generic.  Usable by all the functions and
>        protocols of the AN infrastructure.  It MUST NOT be tied to a
>        particular protocol.

I'm not sure what the last sentence is saying. Do you mean
"MUST NOT be tied to a particular transport protocol" or
"MUST NOT be tied to a particular security protocol"?
Or do you mean "MUST NOT restrict the choice of upper layer
protocol"? Or do you simply mean "MUST provide a generic
IPv6 service"?

Also, there's no requirement about performance or the
expected traffic density. Should we say something either
in the Requirements section or in the Notes in the
Overview section? I assume that performance is not critical
and ACP traffic density is expected to be low.

> 5.  Overview
...
>   Default policy is: To all adjacent nodes in the
>   same domain.

I know this is explained later, but I think both
"adjacent" and "domain" need some qualification.
For example:

  Default policy is: To all adjacent link-layer autonomic
  nodes in the same autonomic domain.

...
>    5.  Inside the ACP VRF, each node sets up a virtual (loopback)
>        interface with its ULA IPv6 address.

I think we have cases where a node has multiple ULAs.

> 6.1.  Domain Certificate
> 
>    To establish an ACP securely, an ACP device MUST have a globally
>    unique domain certificate (LDevID),...

You need a normative reference for the LDevID format.

> 6.1.1.  ACP information
> 
>    The domain certificate (LDevID) of an autonomic node MUST contain ACP
>    specific information, specifically the domain name, the address of
>    the device in the ACP with the Zone-ID set to zero ("ACP address").

You need a cross-reference for Zone-ID, which is undefined at this point.

...
>    anima.acp+<acp-address>{+<rsub>{+<extensions>}}@<domain>

What notation is that? Is {} supposed to be an optional item?
If so, why not use [] as in ABNF, and cite ABNF.

>  <domain> is used to indicate...

Is that required to respect DNS syntax? If so, please say so.

> {<rsub>.}<domain>

That's wrong. <domain> is preceded by "@" in your syntax, and 
in your example, the dot is in the <extensions> element
"area51.research".

Is there a length limit on the rfc822Name ?

> 6.1.2.  Maintenance

As Michael R said, all the stuff about the registrar
should be in BRSKI, not duplicated here. In fact, it's
very confusing to have it here. If we want a cert
renewal mechanism, surely that's part of BRSKI?

[One detail however:

>    The loop-count MUST be sete to 255.  When an ACP node
>    receives the M_FLOOD, it will have been reduced by the number of hops
>    from the EST server.

I don't like that. The role of the loop count is loop prevention,
so it should be set to a reasonable upper bound on the "radius"
of the network. GRASP has two measures for loop detection, this
one and detection of duplicate session IDs, but that was
intentional redundancy.]

> 6.2.  AN Adjacency Table
> 
>    To know to which nodes to establish an ACP channel, every autonomic
>    node maintains an adjacency table.  The adjacency table contains
>    information about adjacent autonomic nodes, at a minimum: node-ID, IP
>    address, domain, certificate.

Please specify which IP address(es) you mean. Link-Local, ACP
Address(es), or both?

Can you also indicate that an API to this table is needed (at 
least by the GRASP core, and possibly by any ASA that wants to
make direct use of the ACP)?

> 6.3.  Neighbor Discovery with DULL GRASP
...
>           [M_FLOOD, 12340815, h'fe80000000000000c0011001FEEF0000, 1,
>               ["AN_ACP", SYNCH-FLAG, 1, "IKEv2"],
>               [O_IPv6_LOCATOR,
>                    h'fe80000000000000c0011001FEEF0000, UDP, 15000]
>           ]

Once we are fully settled on this I can generate an example and
its binary value for complete clarity. I have one comment which is
that when I last updated draft-carpenter-anima-ani-objectives,
I replaced "SYNCH-FLAG" with "5" (the actual value of the flag
byte) - otherwise you have to define SYNCH-FLAG. Actually
the value 5 indicates discovery+synchronization; everything
should work just the same if it was 4 (synchronization alone),
since it's flooded. I don't know if we care about that difference.

...
>    The ttl and loop-count are fixed at 1 since this is a link-local
>    operation.

No, the ttl is milliseconds - the valid lifetime of the flood.
You have that correct in your version of AN_join_registrar.

> 6.8.2.  ACP as the Security and Transport substrate for GRASP
...
>    GRASP inside the ACP uses link-local UDP IPv6 multicast across the
>    ACP virtual interfaces for GRASP neighbor discovery...

and flooding

Also, you might want to add a reminder that GRASP does its own
relaying of multicast packets between interfaces; the ACP is
not required to provide multicast routing.

>                                                  ...and IPv6 over TLS
>    across the ACP virtual interfaces for any of its unicast messages.

Wait, what are you saying here? Do you really mean IPv6
over TLS, or TLS over TCP over IPv6?

As Eric Rescorla asked us at one point, please draw a ladder
diagram of the protocol stack.

...
>    TLS is mandated for GRASP because the ACP secure channel mandatory
>    authentication and encryption protects only against attacks from the
>    outside but not against attacks from the inside - compromised ACP
>    members

I think the threat model really needs a clearer explanation. I assume
that Bob and Alice are good guys, and Eve is a malicious ACP member.
So a packet from Alice to Bob is encrypted from Alice to Eve, decrypted
by Eve, then encrypted from Eve to Bob. So Eve can do what she wants
with the decrypted packet.

Now, who does the TLS wrapping? Will that be done by the ACP,
or by the GRASP core? If the latter, you still need to explain
how the ACP conveys the cert information to GRASP.

> 6.10.1.  Fundamental Concepts of Autonomic Addressing
...
>    o  Addresses in the ACP are permanent, and do not support temporary
>       addresses as defined in [RFC4941].

Add something like:

  o  Addresses in the ACP are not considered sensitive on
     privacy grounds, so do not need to be pseudo-random
     as discussed in [RFC7721].

(You probably also need to discuss why the ACP is not subject
to scanning attacks: because ULAs are not propagated across
domain boundaries.)

> 6.10.2.  The ACP Addressing Base Scheme
> 
>    The Base ULA addressing scheme for autonomic nodes has the following
>    format:
> 
>   8      40             2                     78
> +--+-----------------+------+------------------------------------------+
> |FD| hash(subdomain) | Type |             (sub-scheme)                 |
> +--+-----------------+------+------------------------------------------+
> 
>                    Figure 2: ACP Addressing Base Scheme
> 
>    The first 48 bits follow the ULA scheme, as defined in [RFC4193], to
>    which a type field is added:
> 
>    o  "FD" identifies a locally defined ULA address.

For the Nth time, please s/FD/fd/ as required by RFC5952

> 
>    o  Type: This field allows different address sub-schemes in the
>       future.  The goal is to start with a single sub-schemes, but to
>       allow for extensions later if and when required.  This addresses
>       the "upgradability" requirement.  Assignment of types for this
>       field should be maintained by IANA.

You need to write precise directions to IANA.

> 6.10.3.  ACP Zone Addressing Sub-Scheme
> 
>    The sub-scheme defined here is defined by the Type value 0 (zero) in
>    the base scheme.
> 
>            51            1     13                    63             1
>  +---------------------+---+---------+-----------------------------+---+
>  |    (base scheme)    | Z | Zone-ID |         Device-ID           | V |
>  |                     |   |         | Registrar-ID | Device-Number|   |
>  +---------------------+---+---------+--------------+--------------+---+
>                                              48           15

s/51/50/

Although I think it would be simpler to do this:

           48        2   1     13                    63             1
 +----------------+----+---+---------+-----------------------------+---+
 | ULA prefix     |Type| Z | Zone-ID |         Device-ID           | V |
 |                | 00 |   |         | Registrar-ID | Device-Number|   |
 +----------------+----+---+---------+--------------+--------------+---+
                                             48           15

> 
> 6.10.4.  ACP V8 Addressing Sub-Scheme
> 
>    The sub-scheme defined here is defined by the Type value 1 (one) in
>    the base scheme.
> 
>              51                           63                 8
>    +---------------------+-----------------------------+----------+
>    |    (base scheme)    |         Device-ID           |        V |
>    |                     | Registrar-ID | Device-Number|          |
>    +---------------------+--------------+--------------+----------+
>                                46             32

Same comments.

> 6.10.5.  Other ACP Addressing Sub-Schemes
> 
>    Other ACP addressing sub-schemes can be defined if and when required.
>    IANA would need to assign a new "type" for each new addressing sub-
>    scheme.  With the current allocations, 5 more schemes are possible

That's confusing. In your terminology, only two more types are
possible (10 and 11). It would be simpler to simply define 3 type
bits.

A general remark: when a wider audience looks at this, there will
be complaints that we are re-creating classful addressing. I suggest
adding some text about this. (Along the lines of: it's true, and
here is why it doesn't matter.)

>    Every ACP device (RPL node) announces an IPv7 prefix

Forward into the future!

> 6.12.4.  ACP interfaces
...
>    These packets are of course redundant (unnecessary) and would be
>    discarded by GRASP on receipt as duplicates.

...by use of the GRASP Session ID.

> 7.2.  How (per L2 port DULL GRASP)
...
> L3/L2 devices SHOULD support per-L2 port ACP.

Clarify that ACP (and GRASP) capable devices do
not need to depend on MLD snooping, since they
catch LL multicasts directly per port. But non-ACP
switches MUST either support MLDv2 snooping or
operate as pure L2 bridges for all multicast
packets.

Also, is there anything to say here about VLANs?
 
> 11.  Security Considerations

I think you need to insert cross-references to
various security discussions elswhere in the draft.
 
> 12.  IANA Considerations

TBD!

Nits:
-----

> 2.  Terminology
...
>    ACP VRF  The ACP is modelled in this document as a "Virtual Routing
>       and Forwarding" (VRF) component in a network device.

I suggest listing this alphabetically as VRF, not under A.

>    AN "Autonomic Network".  A network according to
>       [I-D.ietf-anima-reference-model].  Its main components are Intent,
>       Autonomic Functions and ANI.

I find the second sentence doesn't help, especially by referring to Intent.

  ** The document seems to lack a both a reference to RFC 2119 and the
     recommended RFC 2119 boilerplate, even if it appears to use RFC 2119
     keywords. 

  == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD',
     or 'RECOMMENDED' is not an accepted usage according to RFC 2119.  Please
     use uppercase 'NOT' together with RFC 2119 keywords (if that is what you
     mean).

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 20 Sep 2017 14:46:25 +1200

Hi Toerless,

Slight change of subject header to bring us up to date.

Thanks for all the work. I think the -10 version is much better.

No comments on the -08 to -09 revisions.

On -09 to -10 revisions:

...
> What other cases are you thinking of ?

I forget but I think Michael R had a case for this. Or possibly Michael B.

...

> acp-10: Done. Please check again. Got a lot more complex by using ABNF, but maybe more precise.

Looks OK to me, except for some surviving {} in  {+<extensions>}}

...

On the question of duplicate description of the "AN_join_registrar" objective:

> (renewal, revocation) specification in ACP doc> 

Understood, but we can't have two standards track documents claiming to define
the same objective. If it's *different* from the one in BRSKI it needs a
different name. If it's the *same* one and you are extending its semantics,
you have to say that, and BRSKI becomes a normative reference.

The latest BRSKI draft calls it "AN_registrar" but I assume it is intended to
be the same thing. Anyway I suggest that the ACP authors and the BRSKI authors
agree on what you want. I'm very happy to help with the GRASP details but only
when it's clear what you want.
>   registrar announces AN_join_registrar with both EST-TLS and EST-BRSKI objective values

I agree, it should work.

>   (pretty sure i didn't get the CBOR template not right, but i am sure you get the idea)

Not only do I get the idea, I tested it out many months ago; actually after the
discussions in Berlin, I think. In my Pythonic world it was very easy, but it is
indeed a bit more complicated than the 255-N method.

> I fine either way. I just tried to go for the most simple, logical option.

Right, so the question for the WG (are you all listening?) is whether we
want to defend the value of the loop count in limiting propagation of multicast
messages. (Remember that it has another role in negotiation sessions, where
it really is a loop-prevention counter.)

I will note that in testing on looped topologies I have seen looped multicasts
dropped because of the session ID; theoretically that is sufficient, and the
loop count is logically redundant.

Otherwise, me happy.

Thanks again for all the work,

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Wed, 20 Sep 2017 19:07:26 +0200

Thanks, Brian

a) i will fix the ABNF with next update (for Shengs review).

b) Given the order of likely last calls, i will suggest in the bootstrap meeting that we
   define the AN_Registrar objective authoritatively in ACP and BRSKI adds to it the
   "BRSKI" method. BRSKI already should have no issue having ACP as normative reference.
   Lets see how that discussion goes.

c) Given my ABNF/CDDL dyslexia, would you mind to propose a correct CDDL for the

> >   methd = BRSKI-TLS | EST-TLS | ...

   If we do not get further feedback from the WG supporting my simple TTL=255 approach,
   i would rather go with this structure approach, so that we can let the TTL disussion
   take its natural course (figure out it should be 255 over 10 years ;-P). Primarily,
   because i like the idea to show off a bit the flexiblity of GRASP for the objective
   value being a structure. ANd because it would be a good reference for further objectives
   where we want to discover/select closest instance (and we didn't include this into the
   GRASP document proper).

Cheers
    Toerless

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Sep 2017 14:51:48 +1200

> a) i will fix the ABNF with next update (for Shengs review).

Great.

>    Lets see how that discussion goes.

Works for me. Just decide whether you want AN_registrar or AN_join_registrar.
 
>>>   methd = BRSKI-TLS | EST-TLS | ...

I would go for this:

objective-value = [ sender-ttl, method-list, *[ future-extensions ] ]
method-list = [ +method ]
method = "BRSKI-TLS" / "EST-TLS"
sender-ttl = 0..255
future-extensions = any

The "+" prefix means 1 or more in CDDL and "*" means zero or more.
The commas in lists like [+method] are implied. (I checked
this fragment with the CDDL tool.)

I used strings for the method for simplicity; if you want to save a few
bytes you could use symbols but then they have to be assigned values like
BRSKI-TLS = 0
EST-TLS = 1
and you end up with another IANA registry in your life.

Regards
    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Sep 2017 11:25:12 +1200

By the way, I just realised the obvious: we could write much more
succinct CDDL definitions of objective-values if we wanted to.
For my suggestion below, this means exactly the same:

objective-value = [ 0..255, [ +("BRSKI-TLS" / "EST-TLS") ], *[ any ] ]

Regards
   Brian

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 23 Sep 2017 01:01:53 +0200

Some opinions/suggestions:

a) Name of objective should be "ACP_registrar". The registrar supports multiple
   services, eg: brski-join, est-renewal, and if we had ducklings also est-enroll.

   ACP_*, because it's not AN_* unless we could guarantee we always have intent
    (which we don't), and not ANI_* because we also do not necessarily always have
   BRSKI (but eg: Netconf Zero Touch + ACP).

   But this is terminology. I have an option, but i am happy getting anything that works.
   ultimately i do not care about this part.

b) More importantliy, elements in objective-value should be standardizeable, reuseable, 
   extensible and optional.
   
   AFAIK, for extensible and optionality, we need to use maps instead of
   arrays in CBOR ({} instead of [] in CDDL).

   For standardizeable, we should define the structure to include standards elements

c) The IMHO most easy and useful standardized options are the ones that
   a) allow for objective services to be aligned with DNS-SD so that
   we have a superset of the service-selection facilities of DNS-SD and
   if desired the same name space.

d) So, for the ACP draft, i think i would want to write down the most simple
   subset of the intended syntax for objective-values and not describe the
   background and also not yet start to worry about IANA registration,
   because that would make sense only once we agree on the need of extensibility.
   Worst case, the following syntax would not be extended in future, then
   we just made it a bit more generic than necessary:

    objective-value = {
        std: {
	    sender-ttl: 255,
	    service: { "brski-join" },
	    service: { "est-renew" },
        }
    }

e) In a separate small document we could detail those GRASP aspects in more detail,
   this doc could update ACP RFC, so we can take more time without holding up ACP RFC.
   And we could then also ask for the IANA registries when we feel that there really
   is enough future add-ons to justify the registry.

   Here is my current definition i would use (aka superset of avove example):

  objective-value  = { *parameter }     ; map of parameters to be extensible and
                                        ; all prameters can be optional.

  parameter       /= std: { *std-param } ; create subset of parameters standardized
                                         ; the std-param names would be an IANA registry.

  ; parameter     /= ...                ; Any parameter specific to an objective.

  std-param       /= sender-ttl: 1..255 ; value of ttl field of flood-message
                                        ; as set by sender. Upon receipt, 
			                ; (sender-ttl - ttl) is the distance of 
			                ; the receiver from the sender.

  std-param       /= service: {         ; Services supported by objective.
                         service-name,  ; Name must be registered according to RFC6335
			 *service-param ; would therefore also useable in RFC2782
		     }                  ; For newly registered service names, do not
		                        ; allocate/register protocol/port numbers. These
					; are learned via other GRASP message elements
  service-name     = tstr
                        
  service-param   /= selection-param
  selection-param /= priority: 0..65535 ; Same semantic as rfc2782. Default = 0
  selection-param /= weight:   0..65535 ; Same semantic as rfc2782. Default = 0

   Aka: pretty much allowing 1:1 mapping of the DNS-SD SRV parameters we need
   (service-name, priority, weight) to GRASP "services". And make "services"
   a sub-element of an objective. And RFC6335 also explains why not to use
   capital letters in "est-renew", "brski-join" (uncommon to use capital letters
   in RFC6335).

   As you see, i did not make sender-ttl part of service, so we may use sender-ttl
   even if some objective does not want a "service:" parameter.

   We may need to add locator options to service-params, thats and example of
   how this is yet incomplete. With just one service indicated the locator
   element of the existing GRASP is sufficient.

Cheers
    Toerless

> Works for me. Just decide whether you want AN_registrar or AN_join_registrar.

a) OK, let me obsess about terminology a bit:

I always think of objectives as services, which would make
"XXX_registrar" the right word - it does not prescribe what
to do with the service: ignore, consume(join), buy-stock, resell, attack...

"objective" to me always implies an action, which i think is why
"XXX_join_registrar" was preferred choosen ?

When we, as i suggest have the same registrar objective used for both BRSKI
and EST, we have at least two actions: BRKI-join and EST-renew. Logically
we could also have EST-enroll, but that one is a no-no (eg: ducking enrollment
without voucher).

So we could call what we named "method" also "action" or "service" and
call them BRSKI-join and EST-renew. But those words do then not imply the
transport stack to use (TLS).

I would like XXX = ACP because XXX = AN seems to imply the network is
autonomic, which i think by definition it is not unless we have intent ;-P.
XXX = ANI would also be wrong if for example we combine ACP with Netconf
Zero Touch and only offer EST-renew but not BRSKI-enroll.

b) I would like the parameters of an objective reuseable, extensible and
optional when not needed. I think that we need to use a map instead of
an array in CBOR to get extensibility and optionality (CDDL 

concerned about the word objective - i am never sure if i will not run
into a service where there is really more than

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

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 23 Sep 2017 15:31:44 +1200

>    ultimately i do not care about this part.

Well, settle the name between the ACP and BRSKI authors

>    arrays in CBOR ({} instead of [] in CDDL).

I would argue that in many cases of simple objectives this would be a mistake.
It's a conceptual and practical complication for the ASA writer, unless a
map (and probably JSON) is already "native" for the problem at hand.

I am absolutely not against maps for cases where they are the natural
solution. But if the objective happens to be a simple value, why?

>    if desired the same name space.

Sure, when we are dealing with that sort of objective. (More below on that.)

>    because that would make sense only once we agree on the need of extensibility.

All that IANA registration really requires is a name and a reference document,
so this comes at the RFC stage.

> 	    service: { "est-renew" },

Please work with Carsten to get that right, all I can tell
you is that the tool reports a parse error.
 
>    Here is my current definition i would use (aka superset of avove example):

Again, a parse error.

>    capital letters in "est-renew", "brski-join" (uncommon to use capital letters

All the same, DNS-SD is Unicode, so you can in theory use anything for the
Instance name (human readable part). I agree that the DNS-SD Service name
is case-folded ASCII. 

>    element of the existing GRASP is sufficient.

One more comment below...

> to do with the service: ignore, consume(join), buy-stock, resell, attack...

Well, these objectives and probably many associated with a NOC are
services. But if the ASA is handling some sort of optimisation
or resource management, the objective really is a parameter.
It might be a real number or more complicated, but it's not
a service. Really a GRASP objective is just a container.

> "XXX_join_registrar" was preferred choosen ?

I just tried to copy the terminology in BRSKI.

> and EST, we have at least two actions: BRKI-join and EST-renew. 

Sure, but you can expand the semantics by adding a field to the objective-value
if you want.

> Logically

Maybe you won't in the NOC space, but if we're optimising usage of 
radio links in 3D space maybe you will find complex numbers in
the control loop, and therefore in the objective values.

    Brian

---

From: Toerless Eckert <[email-masked]>
Date: Sat, 23 Sep 2017 08:59:56 +0200

> Well, settle the name between the ACP and BRSKI authors

Sure

> solution. But if the objective happens to be a simple value, why?

As soon as you want to include discovery parameters such as the sender-ttl
or the dns SRV style weight/prio the map for example.

> so this comes at the RFC stage.

Sure. Its more about feeling safe enough that the idea is right
before asking IANA to maintain a registry. Easier done when there
is more time to revisit the decision.

> you is that the tool reports a parse error.

What's the CBOR/CDDL tool you're using, i'll try it myelf first
before yelling for help ;-)

> Instance name (human readable part). I agree that the DNS-SD Service name

I was just trying to follow what seems to be common practice and
minimize the new wheels we're inventing by re--using existing wheels.

> a service. Really a GRASP objective is just a container.

Right. Which is why the objective-value structure proposal also hass
the whole "service" element as an optional subelement only.

> I just tried to copy the terminology in BRSKI.

Yes, pretty sure "join_registrar" was some BRSKI collaborator idea.

> Sure, but you can expand the semantics by adding a field to the
> objective-value if you want.

Thats what the objective-value proposal is doing. 

> the control loop, and therefore in the objective values.

I hope i did mention initialy in my email that the proposed structure
for objetive-value was primarily for flooded objectives and just trying
to establish a structure that allows to define cross-objective shared
eleemnts - without limiting the objective specific ones. 

Cheers
    Toerless

-- 
---
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 Sep 2017 15:35:33 -0400

Toerless, thank you for this version.  We are very very close!
Brian, Max, I invoke your name in my comments... please read and +1,
or disagree with me.

I noticed in this version has two places with no space after the .:

 	   across the network.[RFC7575] defines the fundamental ideas and design
           and it should be re-usable by all autonomic functions.[RFC7575]
           calls

Can we avoid semantic/normative statments like "ACP routing table may include
multiple" in a terminology section?

Change:
ACP (ULA) prefix(es)  The prefixes routed across the ACP.  In the
 	      normal/simple case, the ACP has one ULA prefix, see Section 6.10.
 	      The ACP routing table may include multiple ULA prefixes if the
 	      "rsub" option is used to create addresses from more than one ULA
 	      prefix.  See Section 6.1.1.  The ACP may also include non-ULA
 	      prefixes if those are configured on ACP connect interfaces.  See
 	      Section 8.1.1.

to:
  ACP (ULA) prefix(es)  The prefixes routed across the ACP.  In the
 	      normative case, the ACP has one ULA prefix as specified in
              Section 6.10.  The cases where multiple prefixes are present
              are explained in Section 6.1.1, and use of non-ULA prefixes
              are explained in Section 8.1.1.

There are some good updates to the ACP domain.  I want to bring up this issue
From BRSKI here:
           https://github.com/anima-wg/anima-bootstrap/issues/20

I was suggesting that the information for the Pledge's CSR should be broken
up such that the pledge will create the right CN from the pieces, which it
needs to know anyway. I had suggested:

   "ACPinfo" : { "acp-prefix" : "fda379A6f6ee00000200000064000001",
                    "acp-prefix-length": 96,
                    "acp-plus-part": "area51.research",
                    "acp-domain": "acp.example.com"
   }

I don't like your text:
           If the operator does not own any FQDN, it should
 	   choose am FQDN format string that intends to be equally unique.

I suggest that:
  If they don't own any FQDN, then, aside from WTF?, that they form a
  unique name as: $(uuidgen).example.com.
  Or, perhaps that they use ${ULA}.example.com.

the only real-life situation where this is going to happen is in a test lab
run by co-op students, and in that case, the software might as well have a
pre-configured default.

======

Brian, Max and I asked you to remove the EST requirements on announcements
From the ACP document.

======
   ACP secure channel MUST imediately be terminated when the lifetime of
 	   any certificate in the chain used to authenticate the neighbor
 	   expires or becomes revoked.  Note that is is not standard behavior in
 	   secure channel protocols such as IPsec because the certificate
 	   authentication only influences the setup of the secure channel in
 	   these protocols.

This is rather impractical to implement in real life, that's why IPsec
doesn't do that.  I strongly suggest you sit down with some Cisco, Juniper
(Netscreen) and Checkpoint IPsec product managers, and ask them what they
actually do, and why.

Assuming you really want to have this kind of behaviour, then the correct way
to do this is to make statements about the rekey intervals on the channels.

   ACP secure channels created with the use of certificates will include some
       lifetimes for the certificates. The set of lifetimes includes:
                 1) the expiry date of the certificate
                 2) the lifetime of the OCSP response
                 3) the validity time of the CRL response

       The earliest date provided by these provides a time at which the
       keymanagement channel (e.g. IKEv2 PARENT SA) SHOULD be rekeyed.

6.10.4.  ACP Manual Addressing Sub-Scheme

was changed to:
   The sub-scheme defined here is defined by the Type value 00b (zero)

I think that this is a typo, and should be 01b ?
Or does the Manual mechanism somehow fit into the
   ACP Zone Addressing Sub-Scheme because the Z bit is different?

Do you explain this manual zone better somewhere?

Can you show the two Types with their bits set at the end of the base scheme?

                64                             64
    +---------------------+---------+---++-----------------------------+
    |    (base scheme)  01|Subnet-ID| Z ||     Interface Identifier    |
    +---------------------+---------+---++-----------------------------+
    <-------48--------->TT    13      1

section 8.8.1, starting at:
        The ACP connect interface must be (auto-)configured with an IPv6

seems to be missing articles and/or words, and needs an english editing pass.

====== section 11
           This document may be considered to be updating the IPv6 addressing
 	   architecture ([RFC4291]) and/or the Unique Local IPv6 Unicast
 	   addresses ([RFC4193]) depending on how strict specific statements in

I don't like this statement.  Either it violates the spec, and updates it, or
it does not.  I do not think that it violates.  This is not a multi-link
subnet, this is a prefix that is not on-link.

        It is possible, that this scheme constitutes an update to RFC4191
 	because the same 64 bit subnet prefix is used across many ACP
 	devices.  The ACP Zone addressing Sub-Scheme is very similar to the
 	common operational practices of assigning /128 loopback addresses to
 	network devices from the same /48 or /64 subnet prefix.

It does not. Brian? Do you concur?
        The goal for the 8 or 16-bit addresses available to an ACP device in
        this scheme is to assign them as required to software components,
        which in autonomic networking are called ASA (Autonomic Service

We are not providing 8-bit or 16-bit IIDs.
We are providing 256 or 65536 /128 addresses which are conveniently
aggregated for routing purposes.

 	   In practical terms, the ACP should be enabled to create from its /8
 	   or /16 prefix one or more device internal virtual subnets and to
 	   start software components connected to those virtual subnets.

No, don't say this, and don't do this in practice.  Create /128 routes to LL
address of the internal VM and configure the /128 as a loopback address
inside the VM.

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

---

From: Michael Richardson <[email-masked]>
Date: Sat, 23 Sep 2017 15:43:07 -0400

> loop count is logically redundant.

So, this lets one
    a) notice if the M_FLOOD is forged because the TTL of the underlying
       packet does not agree.
    b) figure out which M_FLOOD is closer.

Given:
    We have ACP built with P2P tunnels between nodes, and on top of
    that we run RPL to form a *unicast* routing topology.

Should a GRASP deamon send M_FLOODs to all P2P tunnels, regardless of whether
they are active RPL routes?    I would tend to say *YES*.

Given that, one will expect to see the same M_FLOOD from the same sender via
multiple paths.  That's fine, and I think it's good.  But, comparing them is
kind of meaningless, because once you find out who the sender is, the unicast
routing takes over, and you will take the unicast direction only.
If one hears announcements from multiple senders, then there might be
different directions, but the TTL you see in the M_FLOOD may have NOTHING to
do with what the unicast cost is.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 24 Sep 2017 09:05:29 +1300

> before yelling for help ;-)

It's a Ruby tool called simply 'cddl'

Install Ruby and then install the gem called cddl.
http://www.rubygemsearch.org/rubygems/cddl

Regards
   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 24 Sep 2017 09:52:48 +1300

Michael,

I get a bit confused by the way your mail agent doesn't distinguish
new and old text, but in line...

> Brian, Max and I asked you to remove the EST requirements on announcements

Toerless explained elsewhere why he thinks the duplication is needed.
 
> Can you show the two Types with their bits set at the end of the base scheme?

As readers of the 6man list know, this has been a very contentious topic.
I think it's safer to duck it in the ACP draft: say what we do, but say
nothing about RFC4291 etc.

> It does not. Brian? Do you concur?

Put it this way. The ACP doesn't assign ULAs using DHCPv6. It doesn't assign
them using SLAAC. It doesn't use conventionally sized /64 subnets. So in that
sense it is like RFC 6164 ("Using 127-Bit IPv6 Prefixes on Inter-Router Links").
But we don't need to apologise. As you say, we're simply assigning /128
addresses to (virtual) interfaces using our own scheme. And we're relying
on BCP 198 (RFC 7608) which says that routing prefixes can be any length
up to /128. If you want to cite anything, cite RFC 7608.

> address of the internal VM and configure the /128 as a loopback address

So yes, I concur with Michael.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 24 Sep 2017 09:58:54 +1300

> they are active RPL routes?    I would tend to say *YES*.

In practice, I think GRASP will send to all the ACP interfaces flagged
as active in the adjacency table. But that amounts to the same thing.

> do with what the unicast cost is.

True, in a general topology - the LL multicasts combined with GRASP relaying
will ammount to a spanning tree rooted at the M_FLOOD sender, but the unicast
paths will be set by RPL. There's no reason they will be congruent. They might
be. This is a good point!

   Brian

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Sep 2017 09:40:20 -0400

> new and old text, but in line...

Well, there isn't any old text in it, rather there are quotes from the document!

    brian> Toerless explained elsewhere why he thinks the duplication is
    brian> needed.

I read that after my email.
I simply can't agree.

    >> subnet, this is a prefix that is not on-link.

    brian> As readers of the 6man list know, this has been a very contentious topic.
    brian> I think it's safer to duck it in the ACP draft: say what we do, but say
    brian> nothing about RFC4291 etc.

I agree.

    > up to /128. If you want to cite anything, cite RFC 7608.

Toerless, do you want text to say this?

    draft> The goal for the 8 or 16-bit addresses available to an ACP device in
    draft> this scheme is to assign them as required to software components,
    draft> which in autonomic networking are called ASA (Autonomic Service

    mcr> We are not providing 8-bit or 16-bit IIDs.
    mcr> We are providing 256 or 65536 /128 addresses which are conveniently
    mcr> aggregated for routing purposes.

    draft> In practical terms, the ACP should be enabled to create from its /8
    draft> or /16 prefix one or more device internal virtual subnets and to
    draft> start software components connected to those virtual subnets.

    mcr> No, don't say this, and don't do this in practice.  Create /128 routes to LL
    mcr> address of the internal VM and configure the /128 as a loopback address
    mcr> inside the VM.

    brian> So yes, I concur with Michael.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Sep 2017 09:44:22 -0400

> be. This is a good point!

As an example, take any ring-like metro-ethernet architecture that an ISP
might deploy.  They have multiple redundant paths across the network, and
they use them for customer data... there is a lot of work going to balance
traffic across such structures.

On top of that, impose a strict DODAG structure with the NOC as the root, and
one can see that ACP traffic between adjacent nodes on a metro-ethernet ring
may well travel all the way to the DODAG root and down again, while an
M_FLOOD will travel sideways.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 25 Sep 2017 09:49:17 -0400

> "XXX_join_registrar" was preferred choosen ?

We used the term "registrar" as the short form of Join Registrar/Coordinator.
After joining, it could be there are other registrars that can be reached to
renew certificates.  Those registrars do not necessarily have to do all of
the EST work with the MASA, etc.

I don't care if it's called XXX_join_registrar or whatever.

I do insist quite strongly that it be described in the BRSKI document.

    > Zero Touch and only offer EST-renew but not BRSKI-enroll.

I don't care which name.

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 25 Sep 2017 21:36:44 +0200

> http://www.rubygemsearch.org/rubygems/cddl

Thanks! [ Cabo: Would be great if the output of cddl generate would
show barewords as strings and not as hexadecimal... ]

> solution. But if the objective happens to be a simple value, why?

Sure. My high level question is how CBOR in IETF can and will establish
a larger framework of pre-defined/reused data types so that app developer
using GRASP (or other protocols with CBOR) could easier reuse existing
data-types when composing new information models. I remember the initial
discussion about how to indicate IPv6 addresses etc. pp.

My simple starting point idea within GRASP is to allow a structure
in which we can start defining such standardized data-types and
reuse them. They would not be at all mandatory, but offered as an
option to objective developers.

The two simple ways to do this is to use a map where the key 'std:' has
a sub-map with standardized keys using standardized value structures.

So, for M_FLOOD of services, which is what we need for ACP and BRSKI,
the standardized parameters i am interested in are:

-> ability to indicate sender-ttl
-> Ability to express service in an RFC2782/RFC6335 compatible
   fashion so that:
   a) We do not have to come up with a registry of our own, but just
      register the services names according to RFC6335
   b) We can perform service selection also compatible with
      RFC2782 if desired (prio/weight).

Appended the fixed syntax that i would want to propose as the structure for
mflood objective values - in a followup draft. In ACP i will just
use the definitions without assuming those will establish a standard
registry - that way we can make the choice whether we like the
idea of this becoming a standard registry for future work.

(oh: and if/when the low-bitrate folks start to complain about
 keys as barewords not being efficient, we can always add 
 a numerical registration based map option.)

Cheers
    Toerless

objective-value  = mflood-ovalue

; objective-value in M_FLOOD:
mflood-ovalue   /= { 1*parameter }

; Standardized parameter:
parameter      //= ( std: { 1*std-param } )

; Any non-standardized objective-value elements can be
; added by objectives in two ways:
; a) add to parameters (any map/tlv where the type is not 'std').
; This allows to have both std-param and objective specific params
; together
; parameter    //= ...
; b) choose a different value for mflood-ovalue, eg:
; string or list. Then you can not use std-param
; mflood-ovalue   /= ...

; value of ttl field of flood-message as set by sender.
; Upon receipt, (sender-ttl - ttl) is the distance of
; the receiver from the sender.
std-param      //= ( grasp-sender-ttl: 1..255 )

; DNS-SD compatible service supported by objective.
; service-name must be registered according to RFC6335
; an would therefore also useable in RFC2782 (DNS-SD)
; Do not register protocol/port numbers for new services
; unless there is a good reason. When using GRASP/ACP,
; protocol/port can be dynamically discovered.

std-param      //= ( service: service )
service          =  { service-name , *service-param }
; Same syntax, guidelines as service name in rfc2782
service-name     = ( name: tstr )
service-param    = selection-param
; Same semantic as rfc2782. Default = 0
selection-param //= ( priority: 0..65535 )
selection-param //= ( weight:   0..65535 )

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Sep 2017 08:38:08 +1300

Separating out one issue:

> Brian E Carpenter <[email-masked]> wrote:

[Discussing whether the ACP draft or the BRKSI draft or both
should define the GRASP objective AN_join_registrar]

> I read that after my email.

As a general matter, what do people in the WG think we should do
when different aspects of the same objective are defined in different
drafts? There are at least three possible solutions:

1. Accept this situation; both documents will be references for the IANA
registry at
https://www.iana.org/assignments/grasp-parameters/grasp-parameters.xhtml#objective-names
2. Forbid this situation.
3. Have the complete definition in document A and make a normative reference
to it in document B.

     Brian

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 25 Sep 2017 22:18:14 +0200

> I read that after my email.

I don't think i was suggesting duplication. I was suggesting for
one document to define an extensibel objective and the other draft to
extend it. 

The extensibel notation i was suggesting would also result in the
definition of a brski-enrol service name that would be useable outside
of ACP, eg: when you just use DNS-SD without ACP in some instance of BRSKI.

>     brian> nothing about RFC4291 etc.

I can easily remove the whole section 11 from the ACP document and we can bring it
back if/when 6man review is asking for it, no problem.

> Toerless, do you want text to say this?

Always happy to get text suggested, but please also with a fitting place,
especially if you do not like section 11. And then do not blame me if we
again get more and more explanatory text into standards sections ;-P (which i do
like, but which normal IETF reviewer usually bitch about).

>     mcr> aggregated for routing purposes.

Hmm... I guess you are implying but also prefer not to explicitly say:
-> If an implementation wants to pick any shorter than /127 prefix from thiss
block of addresses to assign to a subnet, then it's up to that implementation
to argue how such an implementation will fit the IPv6 architecture. The 
ACP document does no require or prescribe any such approaches.

>     brian> So yes, I concur with Michael.

Ok, let me see how to best deal with this all.

-- 
---
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Sep 2017 12:28:23 +1300

Here's confirmation that your CDDL generates a valid objective-value.
In the attached, you will find 8 Python statements and the resulting
output from a GRASP instance talking to itself.

If there's consensus to go this way I can update my demo code
for the BRSKI actors accordingly. But we need some WG discussion
about that, and I need to learn a bit about using maps in Python :-).

Regards
   Brian

---

From: Michael Richardson <[email-masked]>
Date: Fri, 29 Sep 2017 13:24:56 -0400

> one document to define an extensibel objective and the other draft to

Objectives are so easy to define and require so little IANA coordination that
I don't see why we would want to extend it without also updating the BRSKI
document.

So to be clear: this is overly general, and I am opposed to this.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 30 Sep 2017 14:03:13 +1300

> So to be clear: this is overly general, and I am opposed to this.

So there are several separate questions here.

1. I understood Toerless to be arguing that the registrar may need to be
contacted again some considerable time after the bootstrap (i.e. join)
action, specifically for what he called EST-renew.

Is that agreed?

2. If yes, would that need a new discovery action?

I assume the answer is yes, since we want to be reasonably
stateless and not assume that we can cache the registrar's address
and port indefinitely.

3. If so, do we want to re-use the same objective (AN_join_registrar
for the sake of argument)? Or would we prefer this to be a distinct
objective?

(I don't think the question would be different in a DNS-SD regime:
one service or two?)

4. In any case, do we want to make this objective or objectives
highly extensible (which basically means using CBOR maps instead
of simple CBOR arrays)? This has the usual pros and cons:
highly extensible = more complex parsing.

There's no doubt this can be done; I've already checked that even
my prototype GRASP code can carry quite complex CBOR structures
transparently. But it does assume that the recipient ASA can
reliably parse them, which is a reasonably complex requirement
for AN infrastructure components.

I don't have preconceived answers to questions 1, 3 and 4. What
do people think?

> of ACP, eg: when you just use DNS-SD without ACP in some instance of BRSKI.

I didn't quite get that. Although we currently require that GRASP
runs over an ACP, there is nothing magic about that. I don't see that
BRSKI actually depends on the ACP either; both would surely run over
bare metal if we told them to (and the Security ADs weren't watching).

    Brian