Last Call Review of draft-ietf-i2rs-protocol-security-requirements-06
review-ietf-i2rs-protocol-security-requirements-06-secdir-lc-perlman-2016-08-19-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.

The document is about the security requirements between a management station
(what I assume a "

I2RS client" is) and the agent on a "routing system". These include mutual
authentication, transport security, atomicity.

The document is well-written and ready, with nits.

I haven't been following this WG, so apologies for perhaps not getting the
terminology, though it might be better if every document were self contained,
in defining terms, or pointing to a different document where all the terms are
defined.

The meaning of the  term in the spec  "

routing system" is not obvious to me.  I'm assuming it means not only routers
but anything that looks at layer 3 such as load splitters and hypervisors, is
that correct?  Maybe the term is defined in a different document?  If not, a
clarifying sentence would be appreciated by readers.

In section "

I2RS multi-message atomicity"

"this is not

 supported in order to simply the first version of I2RS"

should be "simplify"

"

If insecure transport is used, then

confidentiality and integrity cannot be achieved"

That statement, as a sweeping statement, isn't true, since, for instance,
Ethernet does not provide any confidentiality and integrity, but protocols can
achieve confidentiality and integrity by doing it themselves.  So perhaps the
statement should be softened to say something like "I2RS does not itself
provide confidentiality and integrity, so it depends on running over a secure
Transport that provides these features".

"

All I2RS clients and I2RS agents MUST have an

identity, and at least one unique identifier that uniquely

identifies each party in the I2RS protocol context."

This might be overly restrictive.  You might want several I2RS clients acting
as instances of a single identity, in which case, they might all share the same
identity.

" SEC-REQ-06: The I2RS protocol SHOULD assume some mechanism (IETF
      or private) will distribute or load identifiers so that the I2RS
      client/agent has these identifiers prior to the I2RS protocol
      establishing a connection between I2RS client and I2RS agent."

Instead of "distribute or load", perhaps "configure" would be clearer?  At any
rate, I don't know the difference between "distribute" and "load".

Radia