Last Call Review of draft-ietf-storm-iscsi-sam-
review-ietf-storm-iscsi-sam-secdir-lc-melnikov-2012-08-01-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 iSCSI protocol as specified in [draft-ietf-storm-iscsi-cons-xx] (and 


as previously specified by the combination of RFC 3720 and RFC 5048) is 


based on the SAM-2 (SCSI Architecture Model - 2) version of the SCSI 


family of protocols. This document defines enhancements to the iSCSI 


protocol to support certain additional features of the SCSI protocol 


that were defined in SAM-3, SAM-4, and SAM-5. In particular the document 


adds:




 1) Command Priority field
 2) Several new commands:

    9 - QUERY TASK - determines if the command identified by the
    Referenced Task Tag field is present in the task set.

    10 - QUERY TASK SET - determine if any command is present in
    the task set for the I_T_L Nexus on which the task management
    function was received.

    11 - I_T NEXUS RESET - perform an I_T nexus loss function (see
    [SAM5]) for the I_T nexus on which the task management
    function was received.

    12 - QUERY ASYNCHRONOUS EVENT - determine if there is a unit
    attention condition or a deferred error pending for the I_T_L
    nexus on which the task management function was received.

And a new response code that they use.



The document sends readers to review Security Considerations from RFC 


3720. This is probably appropriate, as extensions added by this document 


are minor and don't seem to change iSCSI model much. One thing that 


might be missing is some text about abuse of the priority field to 


perform Denial-of-service or to gain better service.






Other comments on the document (consider them minor, but I think editors 


should think about these):






The document can't decide which RFC for iSCSI it is referencing... Which 


one should be used in the new IANA registries created?






Repeating the list of Task Management Functions defined in another 


document is not a good idea. What if another extension adds additional 


functions?