Subject: [Anima] ACP document

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Jul 2017 02:50:22 +0200

I'm reading the -07 version of ACP (because it's been open in a tab
all week as I have written this email slowly. I guess that there is an -08
version that I will look at when I've got network again)

5.1.1 says:
      domain certificate can automatically and securely be derived from a

I think the word "derived" is wrong. That implies that there is some kind
of mathematical relationship between the certificates.  BRSKI permits these
ACP certificates to be automatically and securely *deployed*.

I think it is reasonable to say that BRSKI is not the only way to deploy
those certificates, it's just a zero-touch way.

For some reason, I find the uppercase hex in the ULA unpleasant.  I'd
have made it lower case, but I'm not going to argue this point...

     There are a wide range of pre-existing protocols/services where
     authentication with LDevID is desirable.  Enrolling and
     maintaining separate LDevIDs for each of these protocols/services
     is often undesirable overhead.  Therefore it is beneficial if the
     BRSKI enrolled LDevID can also be used for other protocols/
     services beside the ACP.

A sec-review is going to ask us to name them.  We had better do that.
The thing is that many of those protocols will expect to see subjectAltNames
with useful things in them: for instance an ipv6Address extension with at
least the ula-acp...:1 address is probably a good thing.  I'll bet we can
point to a few things where this would help directly:
      1) SNMP.
      2) https:// access    [server lights out managers: iDrac, iLO...]
      3) ssh   (although it's uncommon to use PKIX, it's not unknown.
               Further, the registrar could populate SSHFP RR into the
               reverse zone)
      4) NETCONF/RESTCONF.
      5) some other SDN north interface, (i2rs, etc.)

paragraph:
      Using an IP address format encoding could result in non-benign
      misinterpretation of the ACP information.
      protocol/services unaware of the ACP could try to do something
      with the ACP address that would fail to work correctly (because it
      is in a different VRF than what they expect), or that could cause
      security issues.

I really think that this is an unsupportable statement.
Chickens *could* also fall from the sky, but outside of certain animated
movies, that doesn't happen.

I'm still unconvinced of the mailbox argument.

NOTE: I am *NOT* arguing against rfc822Name, just that the arguments
need to make sense.

Max: the rfc822Name will need to be included in the CSR.   That means that
the JRC essentially has to do the ULA assignments!   I think that this needs
to be captured into BRSKI.

5.2.3:
   ["AN_ACP", SYNCH-FLAG, 1, "IKEv2"],
             [O_IPv6_LOCATOR,
             h'fe80000000000000c0011001FEEF0000, UDP, 15000]

In this example, you used port 15000.. "(for the sake of creating the
example)"
Is there a reason you did not use 500?
*IF* we are going to run IKEv2 on a non-standard port (but constant across
all ACP nodes), we probably should have a good reason for it.  If it was
your desire to just announce some random port, the issue that can come up
is what happens when a one needs to initiate in the other direction.  Does
one store the port number from the previous announcements?  Does one have
to wait for announcement?  I'd rather just run on port-500.

   Bob becomes passive, he does not attempt to further initiate ACP
   secure channel protocols with Alice and does not consider it to be an
   error when Alice closes secure channels.  Alice becomes the active
   party, continues to attempt setting up secure channel protocols with
   Bob until she arrives at the best one (from her view) that also works
   with Bob.

Perhaps this matters to TCP based or DTLS based protocols, but IKEv2 doesn't
care about this.

   assume that neighbors with the same L2 or link-local IPv6 addresses
   on different L2 interfaces are the ame devices.  This can only be
   determined after examining the certificate after a successful
   security association attempt.

I thought I'd find strong language saying exactly that in
  https://tools.ietf.org/html/rfc4291#section-2.5.6
that we could reference, but, I don't see such a statement.  Maybe it's
somewhere else?

I think that section 5.5 should include a final paragraph to the effect of:
  While the rfc822name includes the ACP ULA address, the actual negotiation
  in each of the protocols will usually be from a Link-Local address of the
  autonomic node. (Or, in the case of MACsec, from the L2 address)
  As such, it is not possible to match the rfc822name to the device
  negotiating in any meaningful way.

5.6.1.1:
  change: AES256 encryption and SHA256 hash.
  to: and MUST support the current MUST and SHOULD+ modes specified
      in draft-ietf-ipsecme-rfc7321bis and draft-ietf-ipsecme-rfc4307bis
      Signature modes
      for IKEv2 PARENTs are determined by the algorithms used in the
      certificates.

We haven't said anything about certificate algorithms.
I'd like to make EdDSA Curve25519 a SHOULD+.
I suspect will have to make ECDSA secp256p1 a MUST, which makes me unhappy.
I am okay with having RSA >= 2048 be a MAY.
(RSA < 2048 is a SOULD NOT)

6.1 ACP connect

ACP connect has *ADDRESSING* issues not covered!
It will likely need to issue RAs on the ACP connect interface, so it
must be given a /64.  In the -07 address plan, I would propose that each ACP
connect interface will adopt a zoneID.  In some newer plan, we just need
to make sure that we can agree on whatever the upper-(64-x) bits are which
are not the "base scheme"

I propose that we should have a GRASP ANI to allocate zoneIDs (if we keep
them) that would be built into any ACP nodes that intend to have ACP connect
interfaces.

There may well be *two* (or more) ACP nodes on the same ACP connect LAN!

That is, two routers on the same subnet.  Hardly unusual, it occurs on many
networks, including the IETF conference network.  For IPv4, you have to
run VRRP to make it work, but with IPv6, it just works out of the box.

This would typically be architected using IPv4-centric L2-tricks such that
NMS equipement that needs to be resilient would have master/slave or load
balancing setups in data centers connected via L2 circuits.   There would be
an ACP connect router at each data center.

While we *could* have each of these ACP connect routers allocate their
own zoneID (and thus /64), I suspect that we should be recognizing when
the two ACP connect routers are on the same LAN (an ACP tunnel will be
naturally configured across that L2 fabric).

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

---

From: Michael Richardson <[email-masked]>
Date: Mon, 31 Jul 2017 20:12:51 -0400

All of my minor edits and a few smallish friendly amendments are at:
    https://github.com/anima-wg/autonomic-control-plane/pull/3

    > I'm reading the -07 version of ACP (because it's been open in a tab

Now to the changes in -08:

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

So, I had an initial problem with this, that it referes to something we have
no idea about, "Intent". Then I wondered if this was well defined in the
reference, and I find that actually the reference model has no terminology
section.... maybe one could consider the entire document a terminology
section.  But, it seems strange to be definining this way in *this* document.
I think that it should end at the first period.  If the second sentence is
needed, it should go into the reference.

On this topic (which is not "ACP document"), I'm concerned about the amount
of (*) text in the reference model document!

    AN Domain Name  A string name (typically in a format of a DNS domain
              name) identifying an Autonomic Network.  It is stored in the
              ACP information field of an ANI devices LDevID.

re (typically..) either it's an FQDN (with all the QNAME restrictions and a
reference), or it's just a string.  Let's decide one way or the other, rather
than "typically".

I think that there are a number of other terms which should not be introduced
definitatively in this document....

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

I think we should say that it's a /128.

section 6.1.2 says "Maintenance" but, it's about AN_join_registrar.

I don't think that the AN_join_registrar definition belongs in this document.
I agree that some minor bit of text should exist, but I don't think this
belongs here.  This belongs in BRSKI.
Perhaps it got clipped out in editing, but that's a bug.

section 6.6:
        If our devices certificate indicates a CDP or OCSP then the peers
        certificate must be valid occrding to those (eg: OCSP check across
        the ACP or not listed in the CRL).
        {see git for a grammar fix to above}

Somewhere, I think that we should be saying that Certificate
Distribution Points (CDPs) or OCSP servers (whichever is used) SHOULD be
available via the connections inside the ACP.    BUT, as those things are
usually referenced with names there are some MIF-like isues that I think the
ACP document should address:
1) DNS.
2) address preferences.
(Homenet's naming architecture is dealing with the same questions, but I
think the answers may be different)

6.8.1.  GRASP as a core service of the ACP

I think that this section is really important.
Too important to belong buried in a document about to build secure tunnels
for IP traffic.   At the least, this belongs prominently in the reference
model document.  At the largest, it needs a new document with a title like:
    "The ACP profile of GRASP as a core service"

along with 6.8.2.

re 6.10.2:
   -> 8+40+2 = 50 bits.
   so why in 6.10.3 says, "51 bits" for subscheme.

I don't find the rational for the V bit very convincing. I don't think you
need any real justification for it.

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.

I think you mean, "Type value 01 (one)", since there are two type bits.
I find the use of 1 confusing, given that we also have the Z bit.
You've made me happy with the address definition.

I sent some text via pull request to clarify some of the no-artifact choice
in RPL.  most of the rest of the text looks great to me...
(I just learnt that "artefact" was british spelling for artifact.. I guess we
just need to pick one or the other.)

I'll have to ask Pascal why he suggested:
      Trickle: Not used.

7.1 --- a pretty important section.
One consideration that might be worth doing in a future document is
registering a TLV for LLDP (CDP) that could carry GRASP M_FLOOD ACP
messages. That would please switch fabric vendors because then making the
topologies follow physical would be very easy. LLDP does not get forwarded.

I wonder who knows the right IEEE incantations to do this.

section 10.1: it seems like it's all been said already.
section 10.2 ---> move to an appendix.
section 10.3 ---> appendix or cut.
I see that it all *WAS* in an appendix. I don't know why you moved it.