Early Review of draft-ietf-i2rs-problem-statement-04

Request Review of draft-ietf-i2rs-problem-statement
Requested rev. no specific revision (document currently at 11)
Type Early Review
Team Security Area Directorate (secdir)
Deadline 2016-02-16
Requested 2014-12-18
Authors Alia Atlas, Thomas Nadeau, David Ward
Draft last updated 2015-01-08
Completed reviews Genart Early review of -04 by Russ Housley (diff)
Genart Last Call review of -09 by Russ Housley (diff)
Rtgdir Early review of -06 by Nabil Bitar (diff)
Secdir Early review of -04 by Stephen Kent (diff)
Secdir Last Call review of -09 by Stephen Kent (diff)
Opsdir Early review of -06 by Sarah Banks (diff)
Rtgdir Early review of -04 by Eric Gray (diff)
Assignment Reviewer Stephen Kent
State Completed
Review review-ietf-i2rs-problem-statement-04-secdir-early-kent-2015-01-08
Reviewed rev. 04 (document currently at 11)
Review result Has Issues
Review completed: 2015-01-08


SECDIR early
        review of draft-ietf-i2rs-problem-statement-04



        have reviewed this document as part of the security
        directorate's ongoing effort to review all IETF documents being
        processed by the IESG.



        comments were written with the intent of improving security
        requirements and considerations in IETF drafts. 


        not addressed in last call may be included in AD reviews during
        the IESG review.


        editors and WG chairs should treat these comments just like any
        other last call comments.


This is a
        short document describing the problem being addressed by the
        I2RS WG, and establishing some requirements for solutions.


Section 2
        describes the model for I2RS. It calls for using existing
        transport protocols to provide security, a good statement as
        part of the base protocol requirements. Looking at Figure 1, it
        seems that the only paths that are in scope for I2RS are between
        an I2RS agent and client and between clients. 

In section 5,
        authentication, authorization, and integrity are explicitly
        cited as requirements. This is a good statement of requirements.
        It might be nice to state whether confidentiality is also
        perceived as a requirement, or if it explicitly not a


The Security
        Considerations section is a single paragraph consisting of 2
        sentences. It opens with a nice statement about the importance
        of security in the I2RS context. I think a back pointer to the
        “secure Control” text would be appropriate. The second sentence
        says that more investigation is needed to fully define security
        requirements such as authorization and authentication levels. I
        don’t know what this last phrase means. Authorization (aka
        access control) isn’t usually described as having levels per se.
        Do you mean granularity of access control, or something else.
        Also, for authentication, there are various mechanisms one can
        employ, and these may be described as offering varying “levels”
        of security, but that is an oversimplification in many cases. A
        clearer description of what the authors are trying to convey
        here would be good.


I also
              looked briefly at draft-hares-i2rs-security-02.
              That document begins with a very good discussion of
              security terminology based
              on RFC 4949. It also proposes very specific security
              requirements for communications
              in the I2RS model. That document calls for confidentiality
              as a requirement,
              which further motivates some mention of this security
              service in the problem
              statement, even if the statement is equivocal. 



Two typos I


Section 2:
        measuresments -> measurements


Section 5:


        communications must also have its integrity protected. ->


        communications must also be integrity-protected.