Subject: [secdir] Secdir review of draft-ietf-i2rs-architecture-13

From: Charlie Kaufman <[email-masked]>
Date: Sun, 27 Mar 2016 00:32:02 +0000

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.

I reviewed the -07 version of this document in December 2014. As was true then, this document says very little about security other than the kinds of security mechanisms that are needed. In particular, it does not say what security mechanisms will be used. The document appears to be part of a large suite of documents covering various aspects of this I2RS thing. I would hope the security relevant information appears somewhere else.

I can't resist commenting on some of the things I found confusing. It is likely a lot of my confusion is addressed in related documents. Assuming that's true, it would be helpful if some - perhaps common - introduction to the document suite specified an order in which the documents should be read of avoid forward references.

The document calls itself An Architecture to the Interface to the Routing System. It doesn't say whether this interface is an API or a protocol. Probably both are involved. Section 4 paragraph 1 says "I2RS has been designed to re-utilize existing protocols that carry network management information. Two of the existing protocols which the which may be reused (sic) are NETCONF and RESTCONF." This makes it sound like I2RS is an API. But section 7.2 paragraph 1 says "All such communication channels will use the same higher-layer I2RS protocol (which combines secure transport and I2RS contextural information). This makes it sound like a protocol.

Section 4.1 paragraph 2 talks about application identity, but it wasn't clear (at least to me) whether it was referring to the application as code and protocol (e.g., Wireshark) or as the owner of the instance of the application to determine permissions.

Section 6.4.2 says "Directly writing to these protocol-specific RIBs or databases is out of scope for I2RS" but says "joining/removing interfaces from multicast trees" was a supported operation. Doesn't that involve directly updating a protocol-specific database?

Section 7.6 says any given piece of information... (should only be)... manipulated by a single I2RS Client. But section 4.3 says there should be multiple clients running with the same client identity. This leaves ambiguous how the clients are supposed to coordinate and whether (for example) both will get copies of notifications the client identity has signed up for.

Nits (typos/language):

Section 4 para 1: "which the which may" -> "which may"
Section 4 para 1: "existing protocol in order" -> "existing protocols in order"
Section 4 para 5: "I2RSS" -> "I2RS"
Section 6.3 para 1: First ref to "yang data model" should have reference.
Section 7.4 para 1: "value ranges for portion of scope policy" -> ???
Section 7.5 para 3: "mechanism instantiated" -> "mechanisms instantiated"