[Anima] ACP document

[Michael Richardson <[e-mail]>]

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