Skip to main content

Telechat Review of draft-ietf-anima-bootstrapping-keyinfra-28

Request Review of draft-ietf-anima-bootstrapping-keyinfra
Requested revision No specific revision (document currently at 45)
Type Telechat Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2019-10-15
Requested 2019-10-01
Authors Max Pritikin , Michael Richardson , Toerless Eckert , Michael H. Behringer , Kent Watsen
I-D last updated 2019-10-13
Completed reviews Iotdir Telechat review of -17 by Russ Housley (diff)
Secdir Last Call review of -16 by Christian Huitema (diff)
Genart Last Call review of -16 by Jari Arkko (diff)
Secdir Last Call review of -20 by Christian Huitema (diff)
Secdir Telechat review of -28 by Christian Huitema (diff)
Genart Telechat review of -28 by Dan Romascanu (diff)
Assignment Reviewer Dan Romascanu
State Completed
Request Telechat review on draft-ietf-anima-bootstrapping-keyinfra by General Area Review Team (Gen-ART) Assigned
Posted at
Reviewed revision 28 (document currently at 45)
Result Ready w/issues
Completed 2019-10-13
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please wait for direction from your
document shepherd or AD before posting a new version of the draft.

For more information, please see the FAQ at


Document: draft-ietf-anima-bootstrapping-keyinfra-??
Reviewer: Dan Romascanu
Review Date: 2019-10-13
IETF LC End Date: None
IESG Telechat date: 2019-10-17

Summary: Ready with Issues

This document specifies automated bootstrapping of an Autonomic Control Plane
by creating a Remote Secure Key Infrastructure (acronym BRSKI) using
manufacturer installed X.509 certificates, in combination with a manufacturer's
authorizing service, both online and offline.

Christian Huitema and Jari Arkko have performed early reviews of previous
versions of the document for SecDir and Gen-ART. As far as I can tell, most if
not all of their major concerns concerning applicability and security have been
addressed in the latest versions. A few more minor issues described below would
better be clarified before approval.

I also observe that the document has consistent Operational implications but
there is no OPS-DIR review so far, as well as a YANG module and several other
references to YANG, but there is no YANG Doctors review. I hope that these will
be available prior to the IESG review.

Major issues:

Minor issues:

1. The Pledge definition in section 1.2:

> Pledge:  The prospective device, which has an identity installed at
      the factory.

while in the Introduction:

> ... new (unconfigured) devices that are called pledges in this

These two definitions seem different. The definition in 1.2 does not include
the fact that the device is 'new (unconfigured'. Also, arguably 'identity
installed at the factory' may be considered a form of configuration.

2. The document lacks an Operational Considerations section, which I believe is
needed, taking into consideration the length and complexity of the document.
There are many operational issues spread across the document concerning the
type and resources of devices, speed of the bootstrapping process, migration
pass, impact on network operation. I suggest to consider adding such a section
pointing to the place where these issues are discussed and adding the necessary
information if missing. Appendix A.1 in RFC 5706 can be used as a checklist of
the issues to be discussed in such a section.

3. Section 5.4:

> Use of TLS 1.3 (or newer) is encouraged.  TLS 1.2 or newer is

What is the reason for using 'encouraged'? Why not RECOMMENDED?

Nits/editorial comments:

1. The Abstract includes:

'To do this a Remote Secure Key Infrastructure (BRSKI) is created'

Later in the document BRSKI is idefined as a protocol. It would be good to
clarify if BRSKI = BRSKI protocol

2. In Section 1 - Introduction, 3rd paragraph:

s/it's default modes/its default modes/
s/it's strongest modes/its strongest modes/

3. Please expand non-obvious acronyms at first occurrence: EST protocol, LLNs,

4. I would suggest alphabetic order listing of the terms in section 1.2

5. Section 1.3.1 - a reference for LDevID would be useful

6. Section 7:

s/Use of the suggested mechanism/Use of the suggested mechanisms/