[Int-dir] An IOT DIR review of draft-ietf-anima-autonomic-control-plane

["Pascal Thubert (pthubert)" <[e-mail]>]

Reviewer: Pascal Thubert on behalf of IOT-DIR;



I am an assigned IoT directorate reviewer for draft-ietf-anima-autonomic-control-plane-13.



These comments were written primarily for the benefit of the INT and OPS Areas Directors from the IoT perspective. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the IoT Directorate, please see https://datatracker.ietf.org/group/iotdir/about/ and for Directorates in general please see https://www.ietf.org/about/groups/directorates/.



I'll be away for  the next 2 weeks and could not finish the review in time for this heavy document, but at least I made it through till the RPL section. In the interest of time, let me share what I already have.



Summary

-------------



The summary of the review is that the document is Ready for Publication, with comments.





Major comments

------------------------



-          " in-band" and "out of band network "

should be defined since it is fundamental to understand that the ACP takes place in the same physical links as the data plane, as opposed to dedicated management ports (correct?);



-          Section 3; the IOT certainly could use an ACP. It would be useful to scope the feature that is proposed in this document, whether it is compatible of not with constrained environments, whether it needs adaptations, point on Michael's enrollment draft. It would also be useful to indicate whether the ACP works between L3 bridges, IOW whether ACP operates the same (over IP) regardless of the packet forwarding layer in the data plane;



-         " Inside the ACP VRF, each node sets up a loopback interface with its ULA IPv6 address"
This is the first time, IPv6 is discussed; would have been nice to introduce that the Node has IPv6, that it needs a ULA and that ACP assigns it. This discussion could be done in conjunction with the comment above;



-         About  "The ttl

parameter SHOULD be 3.5 times the period so that up to three

consecutive messages can be dropped before considering an

-           announcement expired. "

This is the only discussion on the ttl field of the M_FLOOD. Though its meaning is quite obvious, the behavior associated to it should be defined.



-         "In the above (recommended) example the period of sending of the"

Is this RECOMMENDED IOW normative??



-         Text P 25 says "At this time in the lifecycle of ACP nodes, it is unclear whether it

is feasible to even decide on a single MTI (mandatory to implement)

security association protocol across all ACP nodes"

but then P27 "It MUST support ESP

with AES256 for encryption and SHA256 hash and MUST NOT permit weaker

crypto options."

and then "   A baseline ACP node MUST support IPsec natively and MAY support IPsec

via GRE. A constrained ACP node MUST support dTLS.  ACP nodes

connecting constrained areas with baseline areas MUST therefore

support IPsec and dTLS."

Seems that text P25 should go?





-           "Use-ULA: For loopback interfaces of ACP nodes, we use Unique Local

Addresses (ULA), specifically ULA-Random, as defined in [[RFC4193]

with L=1]."

This needs to be more crisp. ULA is defined in RFC 4193 but the term ULA-Random is not. I think you mean that 3.2.2.  of RFC 4193 is the way addresses are formed, if so please say so.  The best practice RFC 8064 recommends use of RFC 7217. I understand that privacy is not a concern but does it hurt? Anyway please point at section 6.10 and 6.11.1.11





-           "

RPL Mode of Operations (MOP): mode 3 "Storing Mode of Operations with multicast support".  Implementations should support also other modes.

Note: Root indicates mode in DIO flow"

Why "should" ? there is no much point supporting the other modes is there? Section 6.11.1.13 says that SRH is not used so this is inconsistent. You only need MOP 2 or 3, 3 is you do multicast which at the moment does not appear to be the case. SO I would MUST a MOP of 2 and MAY a MOP of 3 which is a superset of MOP 2, and that's it (see 6.3.1 of RFC 6550).





-           "The lack of a RPI (the header defined by [RFC6553]), means that the

data-plane will have no rank value that can be used to detect loops.

As a result, traffic may loop until the TTL of the packet reaches

zero. "

Since we have reliable links and no stretch (section 6.11.1.7), loops should be exceedingly rare. It could be recommended to send the DIOs 2-3 times to inform children when losing the last parent. Note that the technique in section "8.2.2.6.  Detaching" of RFC 6550 should be favored over that in section "8.2.2.5.  Poisoning" because it allows local connectivity. Also, It should be said that a node should select more than one parent, at least 3 if possible, and send DAOs to all of then in parallel. This provides multi





-           "ACP nodes MUST perform standard IPv6 operations across ACP virtual

interfaces including SLAAC (Stateless Address Auto-Configuration -

RFC4862])"

They may actually prefer Optimistic DAD RFC 4429 since address duplication is highly improbable as long as you .





Minor comments

------------------------





-         About "[RFC7575] defines the fundamental ...  "

for readability, it may be nicer to indicate the title of an RFC when it is referenced first; e.g. the text above would become

" Autonomic Networking: Definitions and Design Goals" [RFC7575] defines the fundamental ...



-         about "or network plane (there is no well-established name  for this)"

The term network plane is not used again in the document. This text may go away. You may consider using "security and transport substrate" instead, since it is used elsewhere in the document. Also, please be consistent on whether you use hyphen or not and use that globally, e.g. for the above, and pane like in "forwarding plane" or "out of band network ";



-         "data-plen"

Typo?



-         "OAM applications ("Operations Administration and Management)"

Consider using "Operations Administration and Management (OAM) applications " instead; same goes for SDN, ASA, VRF, etc...



-          "   MIC:  "Manufacturer Installed Certificate".  Another word not used in this document to describe an IDevID."

MIC is not used in the document, maybe inform of this equivalence in the IDevID definition instead; same goes for SUDI. Note that UDI is use just once and may not need an entry here.



-               "RPL:  \"IPv6 Routing Protocol for Low-Power and Lossy Networks\".  The routing protocol used in the ACP."

Maybe point on [RFC6550]?


-         "Connecting over non-ACP Layer-3 clouds initially requires a tunnel between ACP nodes."

I understands that it is one tunnel between each pair of adjacent ACP nodes, correct? I read "a tunnel" as an end-to-end tunnel, which sounds different



-          "ACP relies on group security"

Add "The"



-          "An ACP node MUST have keying

   material consisting of a certificate (LDevID), with which it can

     cryptographically assert its membership in the ACP domain and trust

     anchor(s) associated with that certificate with which it can verify

     the membership of other nodes (see Section 6.1.2)."

This is convoluted. Could you make it 2 sentences?



-         "  Note: LDevID ("Local Device IDentification") is the term used to

     indicate a certificate that was provisioned by the owner of a node as

opposed to IDevID ("Initial Device IDentifier") that may has been

loaded on the node during manufacturing time.  Those IDevID do not

include owner and deployment specific information to allows autonomic

establishment of trust for the operations of an ACP domain (e.g.:

between two ACP nodes without relying on any third party)."

LDevID was already defined in the terminology. This text may move there or go away.



-          "   This document uses the term ACP in many places where its reference

document use the word autonomic."

Add [RFC7575] after "reference document"





-          "   "routing-subdomain" is the autonomic subdomain that is used to

calculate the hash for the ULA prefix of the ACP address of the node."

Do you mean ULA suffix?



-          "   o  If the node certificates indicate a CDP (or OCSP) then the peer's

certificate must be valid according to those criteria. e.g.: OCSP

check across the ACP or not listed in the CRL retrieved from the

CDP."

Please define CDP and OSCP, and/or reference a RFC is possible.

Helper: Online Certificate Status Protocol (OCSP)  Certificate Revocation List (CRL) Distribution Point (CDP)



-          "enrolment"

Typo



-          "This can

use a single GRASP M_FLOOD message as shown in above example."

Actually the example is now below. Please reference the figure.



-           "The protocol could for example could have been"

Typo





-           "if the IPsec connecting"

Typo?



-           "ACP wide service discovery"

ACP-wide


-           "if the IPsec connecting In most other solution

designs such distributed discovery does not exist at all or was added

as an afterthought and relied upon inconsistently"

Consider removing or rephrasing : )



-         Maybe consider moving the discussion on multicast P29 -30 to annex? Why Multicast is not used is an interesting discussion but not critical for the protocol operation.



-           "it is not quite clear yet what exactly the implications are

to make GRASP flooding depend on RPL DODAG convergence and how

difficult it would be to let GRASP flooding access the DODAG

information"

Let's chat then. There's work on reliable multicast for RPL using BIER.



-         "In the terminology of GRASP ([I-D.ietf-anima-grasp]), the ACP is the

security and transport substrate for the GRASP instance run inside

the ACP ("ACP GRASP"). "

"running" inside the ACP? Maybe rephrase more globally?

-





-           "OAM protocols no not require IPv4: The ACP may carry OAM "

Typo no->do





-           "Consider a network that has multiple NOCs in different locations.

Only one NOC will become the DODAG root.  Other NOCs will have to

send traffic through the DODAG (tree) rooted in the primary NOC."

A figure would help. I remember all the discussions we had about setting the prf bits in remote NOCs





-           "RPPL."

Typo





-           "Administrative Preference ([RFC6552], 3.2.6  "

The section is correct but that is RFC 6550.





-           "This is a standard issue

with tunneling, not specific to running the ACP across it."

Do you really mean Standard or would Classical work better?





-           "Even though loopback interfaces where originally d"

Typo Where -> were







-         Section 3, 4, 9 and 10 may move to Annex (by moving the section after the </references> tag) since they are not normative and do not contribute to the understanding of the protocol. This way there should not be a need to indicate normative in other sections.



-         Well Noted that Section 14 Will be removed/.





Sorry for being interrupted here,



Pascal