IP Storage (ips) WG Meeting Minutes Monday, March 20, 1300-1500 Dallas, Texas ----------------------------------- Administrivia, agenda bashing, draft status review, etc. - 15 min David L. Black, EMC (chair) Blue sheets Note Well Draft status: - Most drafts are published as RFCs or are in the RFC Editor's queue - iSNS MIB Last Call is done. Minor revision needed to deal with comments from WG's MIB expert, should submit to ADs/IESG in next few months. - Implementers Guide will probably go to WG Last call sometime in 2007. It's ok for this to remain open for a while. Milestones - see charter on web site. iSCSI Implementer's Guide: Mallikarjun Chadalapaka, HP - 1 hour (draft-ietf-ips-iscsi-impl-guide-02.txt) Includes proposed revisions/extensions to SCSI task set management (1) Response Ordering issue - multiple connections may reorder responses from target to initiator. Often not a problem but sometimes SCSI cares (e.g., multi-task abort, ACA). -> Proposed solution: Response Fence to tell iSCSI when response ordering is necessary. Assume that it is always needed for multi-task management and ACA. Would be part of SAM protocol service invocation interface to SCSI transport. Task management already requires this for multi-task operations, proposal is to generalize this in the specification so that it can be defined once, used in multiple places, and made available to T10 (SCSI standards org) to specify it in other places where it is needed. Discussion: This may be difficult to get into SAM-x via T10. There may be a reluctance to deal with multiple connections in a single SCSI session (I_T Nexus). Sense of the room: Response Fence will be added to implementers guide as a general mechanism to deal with SCSI situations that need it. Say that ACA and multi-task management always need it. Can be discussed w/T10, but we're not relying on T10 to pick this up. (2) Task Management - Want to speed-up multi-task abort (ABORT TASK SET, and especially CLEAR TASK SET). Currently have to wait for transfers to complete and status acks to come back. -> Proposed solution: Provide faster TMF completion by avoiding waits for other initiators (can be done without change to initiators) and avoiding wait for other tasks on same initiator (requires new key to negotiate latter, as it involves sending per-LUN async events to cause early transfer teardown vs. current approach of waiting for transfers to complete). Nop-out used to ack async events - will look at combining acks to these events on multiple LUNs for a single target into a single Nop-out. Sense of the room: Clarifications are good - they will not introduce cross-nexus dependencies on the RESET task management functions. Sense of room: New key is useful - put it into draft, allow responder to come back with Yes, No, or Not Understood. SHOULD vs. MAY decision deferred until we have draft text reflecting this. This new key may be related to new T10 data transfer abort service in SAM for SAS - Mallikarjun will follow up with Rob Elliott (SAS expert). iSNS MIB: David Black (WG chair) for Scott Kipp, McData - 10 min (draft-ietf-ips-isns-mib-08.txt) Scope reduced to read-only monitoring of server only. iSCSI X#NodeArchitecture Key: Dave Wysochanski, Network Appliance - 30 min (draft-wysochanski-xkey-iscsi-support-00.txt) Asking for a standard key to allow implementation to say what version of software, etc. it is running. It's easy to get log from one's own product, but harder to get the log from the other side. Declarative key (each side declares it once and may not redeclare it). Security - need to say that *if* confidentiality is an issue, *then* IPsec SHOULD be used. Long discussion of abuse (key used to trigger logic specific to implementation at other end - Javascript had serious problems with this for browsers) and need to use wording in the draft to discourage such abuse. Decision: Draft accepted as WG draft, security and abuse text to be worked out, starting on list. New milestone will be added to charter. Discovery Extension Discussion - John Hufferd, Brocade - 5 min Preference, dealing with multi- environments containing things like InfiniBand and 10 Gigabit Ethernet Seems like a good thing, particularly for protocol flavor supported (iWarp, InfiniBand, etc.). No decisions made - drafts will be considered if/when they appear. iSCSI Security Mechanisms: WG Members - time remaining (if any) The IETF Security Area has requested that IETF Working Groups plan to transition away from usage of MD5. iSCSI CHAP currently uses MD5 in a fashion not directly threatened by the hash collision results known for MD5. It's not clear what to do next - SHA-1 has been registered for CHAP, SHA-256 has not, and RADIUS servers won't support either. Perhaps something in EAP is appropriate. The question that needs to be answered is: What should the next iSCSI authentication mechanism be to supersede the current CHAP/MD5? Note: Post-meeting followup - I took this topic up with the IETF Security Area Directors. Their initial guidance is that the IETF Security Area would not look favorably on use of SHA-256 with CHAP, and they suggest use of SASL in preference to EAP. SASL would also provide a means of cleaning up some issues around how the Kerberos and SPKM mechanisms are currently specified for iSCSI (RFC 3720).