Last Call Review of draft-ietf-opsawg-automated-network-configuration-
review-ietf-opsawg-automated-network-configuration-secdir-lc-austein-2012-08-15-00
| Request | Review of | draft-ietf-opsawg-automated-network-configuration |
|---|---|---|
| Requested revision | No specific revision (document currently at 05) | |
| Type | IETF Last Call Review | |
| Team | Security Area Directorate (secdir) | |
| Deadline | 2012-08-14 | |
| Requested | 2012-08-01 | |
| Authors | Tina Tsou (Ting ZOU) , Jürgen Schönwälder , Yang Shi , Tom Taylor , GuoLiang Yang | |
| I-D last updated | 2024-12-18 (Latest revision 2013-01-23) | |
| Completed reviews |
Genart IETF Last Call review of -??
by Vijay K. Gurbani
Secdir IETF Last Call review of -?? by Rob Austein |
|
| Assignment | Reviewer | Rob Austein |
| State | Completed | |
| Request | IETF Last Call review on draft-ietf-opsawg-automated-network-configuration by Security Area Directorate Assigned | |
| Result | Ready w/nits | |
| Completed | 2012-08-15 |
review-ietf-opsawg-automated-network-configuration-secdir-lc-austein-2012-08-15-00
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
This draft is a problem statement, targeted for Informational status,
discussing issues surrounding automated techniques for configuration
(initial and ongoing) of large numbers of devices, both within a
single organization and when crossing organizational boundaries. The
draft goes into some detail about security issues involved in such
configuration, and emphasizes the difficulty and importance of getting
this stuff right. The Security Considerations section seems adequate,
and the authors deserve credit for resisting the temptation of just
sprinkling IPsec pixie dust all over a fairly hard problem space.
I have no serious security concerns with this document.
Minor notes, in case for whatever reason the authors need to make
other changes:
- The discussion of DNS-based mechanisms for finding the configuration
server probably should mention DNSSEC, at least in passing. At
least in theory, if done properly, DNSSEC would allow the device a
reasonable level of confidence that it has at least obtained the
correct IP address for the configuration server. This does not, of
course, remove the need for mutual authentication when establishing
the secure channel, so the lack of mention of DNSSEC in the current
text is not a critical omission.
- The discussion of UUIDs and shared secrets is a bit confusing.
While I agree with the basic premise (that the combination of UUIDs
and shared secrets may be usable in certain cases but has serious
scaling issues), the discussion does not really cover the inherent
weakness of authentication using such techniques. If one twists
one's head into the right shape, this is indeed a scaling problem of
sorts ("Three can keep a secret, if two of them are dead"), but it
would be better to be explicit about the weakness of authentication
when all you have are UUIDs and a shared secret.