Last Call Review of draft-ietf-i2rs-protocol-security-requirements-06

Request Review of draft-ietf-i2rs-protocol-security-requirements
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2016-08-15
Requested 2016-08-04
Authors Susan Hares, Daniel Migault, Joel Halpern
Draft last updated 2016-08-19
Completed reviews Secdir Last Call review of -06 by Radia Perlman (diff)
Secdir Telechat review of -10 by Radia Perlman (diff)
Opsdir Telechat review of -06 by Mahesh Jethanandani (diff)
Rtgdir Early review of -02 by Tomonori Takeda (diff)
Assignment Reviewer Radia Perlman
State Completed
Review review-ietf-i2rs-protocol-security-requirements-06-secdir-lc-perlman-2016-08-19
Reviewed rev. 06 (document currently at 17)
Review result Has Nits
Review completed: 2016-08-19


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".