Subject: [Anima] some comments/edits on -- draft-ietf-anima-autonomic-control-plane-01

From: Michael Richardson <[email-masked]>
Date: Sun, 29 Nov 2015 16:00:29 -0500

I mentioned a series of comments that I had on the ANIMA documents back in a
thread.  I formed these opinions on the airplane home, here is the first
of my detailed comments.

{I've sent some edits to Michael Behringer via github, see also:
      https://github.com/mcr/anima-control-plane/commit/4d7e60e17502d0b5025014e9cb8ad93dc95f831d

}

1) In (page 2) "Today, the management..." I suggest "console ports" ->
   "console (craft) ports".  I didn't know the term "craft terminal" to refer
   to an out-of-band serial console interface, but apparently that's the
   telco term going back decades.

2) about section 2.3:
   Data plane connectivity can be affected by errors and faults, for
   example certain AAA misconfigurations can lock an administrator out
   of a device; routing or addressing issues can make a device
   unreachable; shutting down interfaces over which a current management
   session is running can lock an admin irreversibly out of the device.
   Traditionally only console access can help recover from such issues.

===> when I was first introduced to the ANIMA ACP concept, one of the things
     that I understood was that the ANIMA ACP might even operate across
     interfaces which were marked administratively down.  I suspect that a
     bunch of platforms can simply physically not do this, and even on ones
     where this can be done,  it may violate expectations of administrators.

     On the other hand, downing an interface is a common shoot-yourself-in-the-foot
     experience that "lock an admin irreversibly out of the device", and is
     a common reason to have the craft terminal place in the first place.

     There are also sometimes changes that require an interface (or line
     card) to be shutdown in order to change the major characteristics of the
     interface.   That can include things like changing what port-based VLAN
     the untagged interface belongs to, changing the lambda for the laser,
     switching from the copper to SPF interface...  Some of these things
     might really cause the ACP to fail on that port.

I think that section 2.3 should mention the "admin down" situation, and
perhaps should introduce some new term which distinguishes between "admin
down" (but ACP up), and "port logically unplugged".

Further, it's clear that the ACP needs to place a requirement on the routing
protocol, which is the ability to for a port to announce that it is "going
away", and to determine what the topology is going to be once that link is
down, and if any other devices will be orphaned as a result.

3) questions about 5.3:
   "
   Autonomic devices may have different capabilities based on the type
   of device, OS version, etc.  To establish a trusted secure ACP
   channel, devices must first negotiate their mutual capabilities in
   the data plane.  This allows for the support of different channel
   types in the future.

   For each node on the candidate ACP neighbor list, capabilities need
   to be exchanged.  The capability negotiation is based on GRASP
   [I-D.ietf-anima-grasp].  The relevant protocol details are defined in
   Section 7.  This negotiation MUST be secure: The identity of the
   other node MUST be validated during capability negotiation, and the
   exchange MUST be authenticated.

   The first parameter to be negotiated is the ACP Channel type.  The
   channel types are defined in Section 8.  Other parameters may be
   added later.
   "

   I find this section to be of extreme concern *as written*.
   Section 7 is essentially unwritten at present.

   a) We can use GRASP to get the list of nodes which might speak
      ACP, and we can even get the list of channel types, which I guess
      would today include the singleton "IKEv2".  (There being no other
      IETF standard secure transports for *IP* packets)

      I don't think that we can validate the identity of the node
      during capability negotiation.

   b) I don't think we want to do capability negotiation in the clear.
      IKEv2 has more than enough facilities for doing this privately,
      and for permitting all kinds of new capabilities to be negotiated.

Section 8 should not list "GRE with IPsec transport", but should list,
"IKEv2".  Whether to do GRE+IPsec or some other structure involving IPsec
(such as IP proto = 98 + transport or IP proto = 4 + transport) can be
negotiated by IKEv2.

4) Section 7's says:

>   This section describes the negotiation exchange in detail.  It is
>   based on GRASP [I-D.ietf-anima-grasp].  Since at the time of
>   establishing the ACP channel there is obviously no ACP yet, this
>   negotiation protocol must run in the data plane.  This negotiation
>   MUST be authenticated, to avoid downgrade attackes, where an attacker
>   injects bogus negotiation messages demanding a less secure ACP
>   channel type.  The negotiation MAY be encrypted.

I don't like the term "data plane" here, I think it's confusing, but I
understand what is being said.  I think we need a different term here.
For ethernet-type wired interfaces, it means doing this:
    1) using link-layer IPv6
    2) over untagged, 802.3 layer
    3) we might even need to say something about a specific default
       lambda, or way to figure out what is being used, etc.

For 802.11-type interfaces, we probably also need to talk about ESSIDs,
ad-hoc vs managed mode, WEP/WPA keys (or lack of them), etc.

As I said above, this negotiation can not be authenticated, nor do we want
any kind of "negotiation" here.  It's just a solicitation of possible peers.
An IKEv2 SA_INIT message sent to a multicast destination would actually work
rather well, and would have the advantage that the GRASP daemon would never
see hostile packets.

section 9.  Self-Healing Properties
...
   >  If an existing device gets revoked, it will automatically be
   >  denied access to the ACP as its domain certificate will be
   >  validated against a Certificate Revocation List during
   >  authentication.  Since the revocation check is only done at the
   >  establishment of a new security association, existing ones are not
   >  automatically torn down.  If an immediate disconnect is required,
   >  existing sessions to a freshly revoked device can be re-set.

This is a pretty sticky issue, I think.
Too much poking into the ACP from management process, I think, and not enough
self-healing.

The IPSEC WG has struggled with this question repeatedly, and in the end came
to the view that IKEv2 SAs and associated IPsec SAs do not expire when the
certificate expires, and that the duration of the CRL does not limit the SA
lifetime.   RFC4945, section 3.2.3 discusses not sending CRLs in-band, and
I was sure that 7296 (IKEv2) said something specific that confirmed this
point, but I can't find it.  It would be best perhaps to limit IKEv2 PARENT
SA lifetimes to something on the order of the CRL lifetime in the ACP context.

<*all for ACP document*>

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