Early Review of draft-ietf-i2rs-protocol-security-requirements-02

Request Review of draft-ietf-i2rs-protocol-security-requirements
Requested rev. no specific revision (document currently at 17)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2016-05-27
Requested 2016-05-05
Draft last updated 2016-05-27
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 Tomonori Takeda
State Completed
Review review-ietf-i2rs-protocol-security-requirements-02-rtgdir-early-takeda-2016-05-27
Reviewed rev. 02 (document currently at 17)
Review result Has Nits
Review completed: 2016-05-27



I have been selected as the Routing Directorate QA reviewer for this draft.

Document: draft-ietf-i2rs-protocol-security-requirements-04.txt
Reviewer: Tomonori Takeda
Review Date: May 20, 2016
Intended Status: Standards Track

I am not following I2RS work closely, but in the spirit of QA review, this is OK in my understanding.


Here are my comments.

I think it is very important to have documents dedicated for security for new protocols such as I2RS protocols.
Overall, I think the document is well organized and clear what are security requirements for I2RS.

Some specific comments.

1) The document is intended to be Standards Track. I do not think it is common for requirement drafts to be Standards Track.

2) In Section 3.1, requirements are mentioned that are set in draft-ietf-i2rs-architecture-15. 
   Some of these requirements are not directly mentioned in draft-ietf-i2rs-architecture-15, 
   but rather implied.

   For example, draft-ietf-i2rs-architecture-15 mentions identifier for I2RS client,
   but does not mention identifier for I2RS agent (IMO).
   Please note that I think requirements mentioned in Section 3.1. makes sense and valid.
   I am just commenting on the way of writing.

3) I think there is dependency on requirements mentioned in this document.
   Specifically, if mutual authentication (Section 3.1), secure transport (Section 3.2),
   and role-based security (Section 3.3) are met, confidentiality (Section 3.3) and 
   integrity (Section 3.4) can be achieved (expect SEC-REQ-16: traceability requirement).

   Perhaps, it depends on in which aspects security requirements should be written
   (in terms of mechanisms or in terms of features). Again, I am just commenting
   on the way of writing.

4) This is just an edit, but in page.10, 
   "Requirements SEC-REQ-13 and SEC-REQ-14" should be
   "Requirements SEC-REQ-14 and SEC-REQ-15".

Tomonori Takeda