2.8.5 IP Storage (ips)

NOTE: This charter is a snapshot of the 51st IETF Meeting in London, England. It may now be out-of-date. Last Modified: 31-Jul-01

Chair(s):

Elizabeth Rodriguez <egrodriguez@lucent.com>
David Black <black_david@emc.com>

Transport Area Director(s):

Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>

Transport Area Advisor:

Allison Mankin <mankin@isi.edu>

Technical Advisor(s):

Keith McCloghrie <kzm@cisco.com>

Mailing Lists:

General Discussion:ips@ece.cmu.edu
To Subscribe: ips-request@ece.cmu.edu
In Body: subscribe ips
Archive: http://ips.pdl.cs.cmu.edu/mail/maillist.html

Description of Working Group:

There is significant interest in using IP-based networks to transport block storage traffic. This group will pursue the pragmatic approach of encapsulating existing protocols, such as SCSI and Fibre Channel, in an IP-based transport or transports. The group will focus on the transport or transports and related issues (e.g., security, naming, discovery, and configuration), as opposed to modifying existing protocols. Standards for the protocols to be encapsulated are controlled by other standards organizations (e.g., T10 [SCSI] and T11 [Fibre Channel]). The WG cannot assume that any changes it desires will be made in these standards, and hence will pursue approaches that do not depend on such changes unless they are unavoidable. In that case the WG will create a document to be forwarded to the standards group responsible for the technology explaining the issue and requesting the desired changes be considered. The WG will endeavor to ensure high quality communications with these standards organizations. The WG will consider whether a layered architecture providing common transport, security, and/or other functionality for its encapsulations is the best technical approach.

The protocols to be encapsulated expect a reliable transport, in that failure to deliver data is considered to be a rare event for which time-consuming recovery at higher levels is acceptable. This has implications for both the choice of transport protocols and design of the encapsulation(s). The WG's encapsulations may require quality of service assurances (e.g., bounded latency) to operate successfully; the WG will consider what assurances are appropriate and how to provide them in shared traffic environments (e.g., the Internet) based on existing IETF QoS mechanisms such as Differentiated Services.

Use of IP-based transports raises issues that do not occur in the existing transports for the protocols to be encapsulated. The WG will address at least the following:

- Congestion control suitable for shared traffic network environments such as the Internet.

- Security measures, including authentication and privacy, sufficient to defend against threats up to and including those that can be expected on a public network.

- Naming and discovery mechanisms for the encapsulated protocols on IP-based networks, including both discovery of resources (e.g., storage) for access by the discovering entity, and discovery for management.

- Management, including appropriate MIB definition(s).

The WG will address security and congestion control as an integral part of bits protocol encapsulation(s); naming, discovery, and management are important related issues, but may be addressed in companion documents.

The WG specifications will provide support for bridges and gateways that connect to existing implementations of the encapsulated protocols. The WG will preserve the approaches to discovery, multi-pathing, booting, and similar issues taken by the protocols it encapsulates to the extent feasible.

It may be necessary for traffic utilizing the WG's encapsulations to pass through Network Address Translators (NATs) and/or firewalls in some circumstances; the WG will endeavor to design NAT- and firewall-friendly protocols that do not dynamically select target ports or require Application Level Gateways.

Effective implementations of some IP transports for the encapsulated protocols are likely to require hardware acceleration; the WG will consider issues concerning the effective implementation of its protocols in hardware.

The standard internet checksum is weaker than the checksums use by other implementations of the protocols to be encapsulated. The WG will consider what levels of data integrity assurance are required and how they should be achieved.

The WG will produce a framework document that provides an overview of the environments in which its encapsulated protocols and related protocols are expected to operate. The WG will produce requirements and specification documents for each protocol encapsulation, and may produce applicability statements. The requirements and specification documents will consider both disk and tape devices, taking note of the variation in scale from single drives to large disk arrays and tape libraries, although the requirements and specifications need not encompass all such devices.

The WG will not work on:

- Extensions to existing protocols such as SCSI and Fibre Channel beyond those strictly necessary for the use of IP-based transports.

- Modifications to internet transport protocols or approaches requiring transport protocol options that are not widely supported, although the WG may recommend use of such options for block storage traffic.

- Support for environments in which significant data loss or data corruption is acceptable.

- File system protocols.

Operational Structure:

Due to the scope of the task and the need for parallel progress on multiple work items, the WG effort is organized as follows:

A technical coordinator will be identified and selected for each protocol encapsulation adopted as a work item by the group. This person will be responsible for coordinating the technical efforts of the group with respect to that encapsulation, working with and motivating the document editors, and evangelizing the group's work within both the community and relevant external organizations such as T10 and T11.

In addition to the normal responsibilities of IETF working group chairs, the IPS chairs hold primary responsibility for selection of coordinators, identifying areas of technical commonality and building cross-technology efforts within the group.

Coordinators for initially important encapsulations:

SCSI over IP (aka iSCSI): John Hufferd (hufferd@us.ibm.com)

Fibre Channel (FC-2) over IP: Murali Rajagopal (muralir@lightsand.com)

iFCP: Franco Travostino (travos@nortelnetworks.com)

Goals and Milestones:

Done

  

Submit the initialprotocol encapsulations as working group Internet-Drafts.

Done

  

Submit initial version of framework document as an Internet-Draft.

Done

  

Discuss drafts and issues at the IETF meeting in San Diego.

Done

  

Discuss framework, specification and related drafts (e.g., MIBs, discovery) for the protocol encapsulations at IETF meeting in Minneapolis.

Done

  

Submit final version of iSCSI requirements draft to the IESG for consideration as Informational RFC.

Done

  

Submit initial Internet-Draft of FCIP/iFCP common encapsulation format

Jun 01

  

Begin revision of WG charter in consultation with the Area Directors.

Aug 01

  

Meet at IETF meeting in London to discuss specification and related drafts (e.g., MIBs, discovery) for the protocol encapsulations

Sep 01

  

Submit protocol specification drafts (iSCSI, FCIP, iFCP, FCIP/iFCP common encapsulation format) to the IESG for consideration as Proposed Standards

Oct 01

  

Submit iSNS and MIB drafts to the IESG for consideration appropriate to each draft.

Internet-Drafts:
No Request For Comments

Current Meeting Report

IP Storage (IPS) Working Group
London Meeting - August 6 and 7, 2001
-------------------------------------

-----) Monday, August 6 (---------

Administrivia and Agenda Bash - see bashed agenda.

Discussion of IETF last call. Process will involve emailed comments directly to authors, so draft editors need to make sure author addresses (including email) are up to date. There is no formal process akin to a T10 or T11 letter ballot and comment resolution.

-- Plugfest - Robert Russell, UNH

Presentation included statistics on number of participants, versions used, etc.

Testing of implementations against each other, a reference implementation, and a conformance test suite (latter two focussed on Login).

Many implementations did not do any Login, most who did only implemented 2 or 3 keys, DataPDULength, InitialR2T, ImmediateData were the most common.

Login was a disaster - all kinds of things not done right, ignored, instability. Most systems wanted to go to full feature phase based on default login values rather than actually engage in negotiation.

Testing also included conformance tests. Statistics are included on foils from Bob Russell. About half of initiators and targets failed to pass conformance tests, and were basically trying to get past key negotiation to full-feature phase.

Set of 20 points were posted to mailing list, most have been dealt with (e.g., strings are null-terminated, not null-separated). See mailing list archives.

Resolved on list - can Initiator stop short of max amount of unsolicited data?

Open Issue - Simplification of Login. Separate security sub-phase, OpParamReset.

Login needs state diagram, specification of legal combinations and sequences.

At least one implementation did perform error recovery, and one pair of implementations were able to establish a multiple connection session.

-- iSCSI Login - Julian Satran, IBM

Login Structure: Lots of parameters. List request for two phases - the two phases are currently implicit, separated by SecurityContextComplete, based on a design goal of minimizing number of handshakes, not programming complexity.

Comments from audience that simpler is better. Complex things tend to have complex failure modes. Need to be careful about adding too many new handshakes as well as too much code.

Programming complexity is a concern to those in the room. Also need to be careful about adding too many handshakes as this can lengthen boot times.

Julian's Proposals:

(3) Both phases explicit but optional.

Discussion: Need a much more structured description. Has too much branching complexity at the moment. Two separate phases with defined transitions between them would help greatly.

Discussion of whether to use SecurityContextComplete key to indicate end of security phase vs. bits in the command. Sense of the room is to continue to use the text key.

The spec needs to include a state diagram (and transition table), and a much more organized (e.g., in one place) description of the login process.

State in the command would help make it clear. The WG sense of the room was that explicitly indicating the login state (e.g., in security or operational negotiation phase) via a few bits of state in the command was preferred to requiring the participants to implicitly track the state (provides a check that things are where the participant thinks they are).

Targets must be able to force security negotiation on an Initiator that wants to skip it.

-- iSCSI Security - David Black

IESG requirements as applied to IPS will make conidentiality and encryption mandatory to implement for iSCSI, FCIP, and iFCP.

Discussion of topics in draft-black-ips-iscsi-security-00.txt (has since been revised to a -01 version). Security decisions will be made in interim meeting in Orange County at the end of August to allow the Fibre Channel folks (currently at T11) to be present since security for the FC encapsulations is likely to follow some of iSCSI's direction.

Discussion of whether identity hiding is needed. No apparent need expressed.

A related proposal to require the Initiator and Target names in the first Login message has lead to adoption of this as a requirement on the list.

Discussion of external gateways. Security community in IETF is concerned that a "just use IPsec gateways" unbinds security from the protocol (could have an arbitrary network between the protocol and gateway) leading to an insecure "hard and crunchy on the outside" (firewalls, etc.), "soft and chewy on the inside" deployment approach. Security is REQUIRED because sooner or later, someone is going to take the protocols we specify and run them on the open Internet.

Q: What about corporate firewalls? Will they block ESP traffic.
A: If they do, have to sent iSCSI without ESP to the firewall or have the firewall terminate the ESP Security Association.

(2) How does one get SPI values and keys from iSCSI negotiation into ESP?
A: Manual key interface, which most IPsec implementations have.

-- IKE and IPsec - William Dixon, Microsoft

Preview of draft-aboba-ips-iscsi-security-00.txt. See that draft. There was also some general discussion of IPsec (how it works, what's available), the phenomenon of keys becoming weaker (easier to break) as a function of how much traffic they've been used for, and the NAT traversal work in progress in the ipsec WG. Use of IKE will be profiled (ips WG will select the portions to use), just as IPsec has been profiled (e.g., just ESP, no AH).

-- Framing - Steph Bailey, Sandburst

All specification of framing mechanisms is being taken out of the main iSCSI draft and will reside in draft-ietf-tsvwg-tcp-ulp-frame-00.txt. A -01 version should be coming in the near future.

Two framing mechanisms are described in that draft:

(1) Periodic Markers - modified receivers, but no modifications to sender's TCP stack. Probabilistic bound on required buffering, but much less than a window per active connection. Hardware will be complex.

(2) PDU Alignment - modified receivers, modified senders to align PDUs to TCP segments. Cleanly bounded buffering, unless alignment fails. Modifications to TCP are needed to detect a middlebox that has resegmented and destroyed alignment.

Each mechanism is applicable to dufferent situations, hence both are in the tsvwg draft. Common interface to both mechanisms.

iSCSI recommendations:

Summary of proposal on what iSCSI should require for framing:

It was not possible to obtain rough consensus in the room on this proposal or a revised version of it presented the following day. Will have to be resolved on list starting from a reasonably detailed explanation of the rationale for these requirements from the framing folks.

-- Error Recovery - Mallikarjun, HP

Reality is somewhere between "Trust but verify" and "can't trust transport".

Four levels of recovery - within-command, -connection, -session, and full session recovery. Only the last is required, others are options.

Command counting is needed for both ordering AND flow control.

Error recovery tools:

Topic 1: SNACK issues (slide 8) Alternatives

Seems to be important for tapes (partial I/O recovery).

Proposal: Keep SNACK, if we drop it we're betting on the TCP checksum (or the ESP MAC). Problem with moderate rate of checksum failure to detect errors

------) Tuesday (---------

SNACK discussion centered on the need for iSCSI error recovery for existing tape. Some current tape devices do things that make SCSI level recovery from a failed command impossible (e.g., send successful completion to write command before actually writing to the tape). There is a new tape command set in the works that will improve this situation by using absolute block addressing for tapes rather than the current relative addressing, but there's a need to deal with existing tape devices.

Sense of the room - keep SNACK, keep it optional, keep it for existing tape because consequences of not having it are horrendous.

Topic 2 - Error Recovery levels, one key to say which level rather than key per type of recovery. 0 would be required recovery, 1-4 are options up to command replay.

Sense of the room - Adopt hierarchical approach to error recovery specification.

Mallikarjun will send paragraphs to list describing each level, what it does over and above the one below it, and what features of iSCSI that it uses.

There was a comment that some levels beyond level 0 in Mallikarjun's chart may need to be "MUST implement" to provide effective support for tape. Needs to be discussed on the list.

--- Main Document - Julian Satran, IBM

See slides for more details.

NOP issue - NOP may close command window. Proposed changes:

In addition, the I bit must be set when immediate data is present

Sense of room is to make these changes - objections should be sent to the list.

Serialization Interlock; this is about being able to preserve command ordering in the presence of things like a CHECK CONDITION caused by a temporary queue full situation. The T10 advice that ACA is not the right solution has been accepted. Julian will follow this up with T10 at their September meeting. The alternative appears to be to use Unit Attention (which has changed in the past year to have properties more useful in this situation) as it only affects a single initiator.

-- Simplification Ideas - David Black

Four proposals resulting from a solicitation for "radical simplification" ideas on the list.

1] Eliminate Multiple Connection sessions - no real interest in pursuing this.

2] Login Templates - take up on list as part of general discussion of Login. This is about organizing all the login keys into a small number of sets where if one key from the set is present, all the keys must be present, and possibly requiring the keys to appear in a particular order.

3] Eliminate CRCs in favor of MACs - take up at interim meeting, although the data CRC was designed to protect against corruption in iSCSI proxies that a MAC would not protect against.

4] Eliminate Immediate data - take to list, at a minimum consider removing the ability to use both immediate and unsolicited data in the same command.

-- Naming and Discovery - John Hufferd, IBM

Specification pieces of N&D are now in main document. Want N&D to become an informational RFC.
Sense of Room - approve this direction, N&D draft to become an informational RFC.

IQN Uniqueness. This is about making sure that the new holder of a domain name doesn't define any iSCSI names that match ones defined by the old holder.

The Area Director commented that IANA is not set up to handle a large number of enterprise number allocation requests, making the second approach preferable.

Sense of room - use date of assignment of domain name to naming authority.

Case Sensitivity

The Area Director noted that the right thing to do was to allow the IDN WG to standardize NAMEPREP. If they abandon it, IPS could pick it up.

Sense of room - Wire format is NAMEPREP'ed names, receivers do bytewise compare, admin tools MUST ensure that all names are in NAMEPREP format (i.e., iSCSI implementations don't have to check this).

Send Targets issues - Bookmarks vs. Option 5 issue will go to the list. N&D team (Mark Bakke?) needs to generate summary of current alternatives to start discussion.

Sense of room - "iscsi" target canonical name MUST NOT be used (reserved).

Issue of whether to include Alias support in protocol. Room was approximately evenly split on this, hence the issue was taken to the list, where the first attempt to resolve it subsequently failed.

-- iSNS - Josh Tseng, Nishan

Relationship of SLP and iSNS: SLP for discovery, iSNS for active management.

iSNS + SLP is better than SLP alone (SLP to discover iSNS, use iSNS services). Will work with SLP community to improve SLP. SLP DA integrates will with iSNS server, providing centralized management of SLP discovery (can still use SLP on wire). Full integration with iSNS client on each iSCSI device improves further (e.g., access list configuration).

iSNS open source will integrate with other databases, e.g. LDAP, MS Active Directory

Sense of room to approve iSNS MIB as an official IPS WG work item - next version will be an official WG draft (draft-ietf-ips-...).

-- SLP Discovery for iSCSI - Marjorie Krueger, HP

Document is getting close to done. Recent changes were to add portal group tags and describe unicast SLP. SLP is moving from proposed to draft standard. RFC 3082 provides SLP notification (currently Experimental).

-- iSCSI MIB - Marjorie Kreuger, HP

UML is done, lots of counters have been discarded. Is mostly consistent with -07.

Need to get work started on SCSI MIB - volunteers should see Marj.

NOTE: did not take up SCSI model mapping to iSCSI - Marj will post recommended rules and pointer to presentation to list.

Slides

iSCSI Security
iSCSI secured with IKE & IPSec
iSCSI Simplification: Some Radical Ideas
iSCSI Naming & Discovery
iSCSI NDT Update on Discovery and Management of iSCSI Devices using SLP and iSNS
iSCSI Error Recovery
iSCSI - a SCSI over TCP mapping