Early Review of draft-ietf-i2rs-problem-statement-04
review-ietf-i2rs-problem-statement-04-secdir-early-kent-2015-01-08-00

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




 




 




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 with the intent of improving security
        requirements and considerations in IETF drafts. 

 

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

  

Document
        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
        requirement. 




 




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
        noted:




 




Section 2:
        measuresments -> measurements




 




Section 5:




 




Such
        communications must also have its integrity protected. ->




 




Such
        communications must also be integrity-protected.