Subject: [Anima] Robert Wilton's No Objection on draft-ietf-anima-autonomic-control-plane-28: (with COMMENT)

From: Robert Wilton via Datatracker <[email-masked]>
Date: Mon, 10 Aug 2020 11:24:45 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-anima-autonomic-control-plane-28: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-anima-autonomic-control-plane/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Hi,

I appreciate that this document has already gone through quite a lot of
reviews.  Just a few minor nits (for the version of the doc that was originally
on the telechat before IETF 108):

    6.1.  ACP Domain, Certificate and Network

       This document uses the term ACP in many places where the Autonomic
       Networking reference documents [RFC7575] and
       [I-D.ietf-anima-reference-model] use the word autonomic.  This is
       done because those reference documents consider (only) fully
       autonomic networks and nodes, but support of ACP does not require
       support for other components of autonomic networks except for relying
       on GRASP and providing security and transport for GRASP.  Therefore
       the word autonomic might be misleading to operators interested in
       only the ACP.

Should this paragraph be somewhere earlier in the document?

    6.1.2.  ACP Certificate AcpNodeName

    The acp-node-name is not
    intended for end user consumption, and there is no protection against
    someone not owning a domain name to simpy choose it.

The latter part of this sentence doesn't seem to scan particularly well.

    6.7.3.1.1.  RFC8221 (IPsec/ESP)

    AH MUST NOT be used (because it does not provide confidentiality).

Do you need AH in the terminology or define what it means?

    6.7.4.  ACP via DTLS

       We define the use of ACP via DTLS in the assumption that it is likely
       the first transport encryption supported in some classes of
       constrained devices because DTLS is already used in those devices but
       IPsec is not, and code-space may be limited.

DTLS in the assumption => DTLS, on the assumption
This paragraph could possibly do with a little more wordsmithing.

    6.10.1.  Fundamental Concepts of Autonomic Addressing

For a PE device or NID, how does it know which interfaces to run ACP over?

       o  OAM protocols do not require IPv4: The ACP may carry OAM
          protocols.  All relevant protocols (SNMP, TFTP, SSH, SCP, Radius,
          Diameter, ...) are available in IPv6.  See also [RFC8368] for how
          ACP could be made to interoperate with IPv4 only OAM.

Should this include a YANG management protocol like NETCONF?
Radius => RADIUS (in a few places)

    6.11.1.14.  Unknown Destinations

       As this requirement raises additional Data-Plane, it does not apply
       to nodes where the administrative parameter to become root
       (Section 6.11.1.12) can always only be 0b001, e.g.: the node does not
       support explicit configuration to be root, or to be ACP registrar or
       to have ACP-connect functionality.

The first sentence doesn't quite scan.

Nits:
retrieved bei neighboring nodes =>  retrieved by neighboring nodes
"serialNumber" contains usually => "serialNumber" usually contains
remotely sent IPv6 link-local => remotely send IPv6 link-local

---

From: Michael Richardson <[email-masked]>
Date: Sun, 23 Aug 2020 17:39:14 -0400

> For a PE device or NID, how does it know which interfaces to run ACP

I think that "PE" here means "Provider Edge"?
The answer is that it runs the GRASP DULL on *ALL* interfaces, because it the
device may have no idea it is a Provider Edge device on that Interface.

A Provider might want to turn this off, and they could well do that once the
device has joined the ACP and gotten management control.  But, the risk of
doing that is that the cables will get plugged in wrong, and the operator
will lose access to the device.

In this case, I think that ANIMA's ACP prefers connectivity over the small
amount of privacy lost by indicating that an IKEv2 is listening on an IPv6
Link-Local address.  There is no security breach possible because the IKEv2
(or DTLS) connection will not complete without the right trust anchors present.

A smart heuristic might be to include some kind of dead-man's switch.
The management interface might turn the DULL off on some interfaces for a
period of time, and if the management interface is lost, then the interfaces
would stop being suppressed.  This falls into the quality of implementation
category at this point.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 24 Aug 2020 10:57:51 +1200

> device may have no idea it is a Provider Edge device on that Interface.

That's correct, and it's safe as Michael indicates.

The ANIMA model does not include an explicit mechanism for defining
domain membership. It's implicitly the set of interfaces that
successfully join the ACP, which also means that the nodes have
successfully performed BRSKI.

IMNSHO there's a big chunk of future work here (see section 6 of
RFC8799), but the current ACP definition doesn't depend on it.

   Brian

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