Re: [secdir] Secdir Review of draft-ietf-storm-iscsi-sam-06

[<[e-mail]>]

Hi Alexey,

Thank you for this review.

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

That would be a good security consideration to add.

> The document can't decide which RFC for iSCSI it is referencing... Which
> one should be used in the new IANA registries created?

Part of what's going on here is that it's not possible to move the replaced
RFCs to historic anytime soon, so RFC 3720 will be a reference for some
iSCSI implementations for many years to come, and it is appropriate to
reference it as the original specification of iSCSI.

That said, I think you've found a couple of things that need attention:
- I think a check of all the references is needed.  One subtlety is that
	the -sam- draft is intended to also be usable with RFC 3720 and
	RFC 5048, but there should be more citations of the consolidated
	draft in the body of the -sam- draft.
- A bunch of IANA text was added to the consolidated draft recently, and
	that includes instructions to IANA about what to reference in the
	registries.  It looks like that set of changes wasn't carried over
	to the new "iSCSI Task Management Response Codes" registry.
We'll get these sorted out - thank you for noticing this concern.
	
> Repeating the list of Task Management Functions defined in another
> document is not a good idea. What if another extension adds additional
> functions?

The primary IETF reference for that is actually an IANA registry, and that
list is actually defined in SAM-2, a SCSI standard.  Nonetheless, I believe
that you're correct, that the list of existing Task Management Functions
in Section 6.1 isn't needed.  

Thanks,
--David

> -----Original Message-----
> From: Alexey Melnikov [mailto:[e-mail]]
> Sent: Wednesday, July 25, 2012 10:22 AM
> To: [e-mail]; [e-mail]; draft-ietf-storm-iscsi-
> [e-mail]
> Subject: Secdir Review of draft-ietf-storm-iscsi-sam-06
> 
> 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?