2.8.6 IP Storage (ips)

NOTE: This charter is a snapshot of the 56th IETF Meeting in San Francisco, California USA. It may now be out-of-date.

Last Modified: 2003-03-07

Elizabeth Rodriguez <ElizabethRodriguez@ieee.org>
David Black <black_david@emc.com>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@psg.com>
Transport Area Advisor:
Allison Mankin <mankin@psg.com>
Technical Advisor(s):
Keith McCloghrie <kzm@cisco.com>
Murali Rajagopal <muralir@cox.net>
Franco Travostino <travos@nortelnetworks.com>
John Hufferd <hufferd@us.ibm.com>
Mailing Lists:
General Discussion: ips@ece.cmu.edu
To Subscribe: ips-request@ece.cmu.edu
In Body: subscribe ips
Archive: http://www.pdl.cmu.edu/mailinglists/ips/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's protocol encapsulations will incorporate the following:

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

- Security including authentication, keyed cryptographic data integrity and confidentiality, sufficient to defend against threats up to and including those that can be expected on a public network. Implementation of basic security functionality will be required, although usage may be optional.

The WG will also address the following issues related to its protocol encapsulations:

- 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) for the encapsulations.

- By agreement with the IESG, the WG will additionally develop MIB definitions for the SCSI and Fiber Channel standards.

The WG specifications will allow the implementation of 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 using 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 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:

Keith McCloghrie (kzm@cisco.com) will serve as the MIB and Network Management advisor for the WG.

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 are responsible 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@cox.net)

iFCP: Franco Travostino (travos@nortelnetworks.com)

Goals and Milestones:
Done  Submit the initial protocol 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
Done  Begin revision of WG charter in consultation with the Area Directors.
Done  Meet at IETF meeting in London to discuss specification and related drafts (e.g., MIBs, discovery) for the protocol encapsulations
Done  WG Last Call on IPS security considerations document.
Done  WG Last Calls on iSCSI, iSCSI naming/discovery, and iSCSI MIB.
Done  WG Last Calls on all WG drafts intended to be published as RFCs, except NAA naming draft
Done  Submit remaining non-MIB protocol drafts intended to be published as RFCs to IESG, except NAA naming draft
JAN 03  Submit all remaining MIB drafts to IESG.
MAR 03  Determine whether to advance NAA naming draft for publication as an RFC in consultation with Technical Committee T10
APR 03  Review with ADs what (if any) additional work the WG should undertake.
MAY 03  Submit NAA naming draft to IESG for publication as an RFC if appropriate
MAY 03  Revise iSCSI boot draft to address security issues and submit to IESG
  • - draft-ietf-ips-fcovertcpip-12.txt
  • - draft-ietf-ips-iscsi-20.txt
  • - draft-ietf-ips-iscsi-boot-09.txt
  • - draft-ietf-ips-isns-18.txt
  • - draft-ietf-ips-ifcp-14.txt
  • - draft-ietf-ips-iscsi-name-disc-09.txt
  • - draft-ietf-ips-fcencapsulation-08.txt
  • - draft-ietf-ips-iscsi-slp-06.txt
  • - draft-ietf-ips-iscsi-mib-09.txt
  • - draft-ietf-ips-fcip-mib-03.txt
  • - draft-ietf-ips-fcip-slp-07.txt
  • - draft-ietf-ips-security-19.txt
  • - draft-ietf-ips-isns-mib-04.txt
  • - draft-ietf-ips-ifcp-mib-05.txt
  • - draft-ietf-ips-scsi-mib-05.txt
  • - draft-ietf-ips-fcmgmt-mib-04.txt
  • - draft-ietf-ips-iscsi-string-prep-04.txt
  • - draft-ietf-ips-auth-mib-04.txt
  • - draft-ietf-ips-fcencap-wglc-01.txt
  • - draft-ietf-ips-fcip-wglc-02.txt
  • - draft-ietf-ips-ifcp-wglcc-00.txt
  • - draft-ietf-ips-iscsi-name-ext-00.txt
  • Request For Comments:
    RFC3347 I Small Computer Systems Interface protocol over the Internet (iSCSI) Requirements and Design Considerations

    Current Meeting Report

    IPS Working Group – Tuesday, March 18, 2003
    Reported by Craig Carlson, Elizabeth Rodriguez & David Black
    Status of Drafts –
    Per the IETF ID Tracker, located at 
    Most thru working group last call.
    A few approved for publication.
    Status:  Publication Requested (these are standards track documents which 
    have just recently been forwarded to the ADs for initial review)
    	Auth MIB
    	FC Mgmt MIB
    	iFCP MIB
    	iSCSI MIB
    Status: AD Evaluation
    	FCIP SLP (has completed expert review.  Same expert review applies to 
    iSCSI SLP)
    	iSCSI SLP
    Status: IESG Evaluation/AD Followup
    	Naming and discovery – Back to ADs for review after revisions made in 
    response to IESG feedback
    Status: IESG Evaluation/Revised ID needed
    	Boot draft sent back due to security problems.  Issues discussed later in 
    Status: RFC Editor Queue (Approved for Publication)
    FC Common Encapsulation
    IPS Security
    These documents are in the RFC Editor Queue and are pending 
    references.  To see the dependencies these drafts are awaiting, see 
    Long pole on the iSCSI RFC assignment is waiting on the AES Counter 
    draft. Possible expedition after references are completed.
    Question was asked about status of FC-BB-2 publication.  Craig Carlson 
    (T11.3 Chair) stated that the ANSI publication process is slow and final 
    publication may not  be available for 6 months.
    Status: ID Exists
    	Three of these drafts (SCSI MIB, FCIP MIB, iSNS MIB) are almost ready to be 
    forwarded.  Nit checks have already occurred, and the drafts are being 
    reviewed by Keith McCloghrie.
    	Three of these drafts (fcencaps-wglc, fcip-wglc, ifcp-wglcc) are drafts 
    written in response to WG Last Call comments, and these drafts will soon be 
    	The Name-Ext draft is a new draft approved as a WG item in Atlanta, and 
    discussed later in the session.
    Boot draft
    Presented by John Hufferd, on behalf of Prasenjit Sarkar
    The boot draft has been sent back to the working group for further work, due 
    to security issues.
    Need to address boot communications security only; Boot image 
    integrity outside purview
    Software stage: not allowed in a secure boot because of integrity issues
    The boot environment is many times extremely constrained verses a fully 
    operational environment.  A limit of 64K is possible.  Need to keep 
    security fairly straightforward; getting too complex takes things 
    Proposal:  Use IPsec (common in wireless networks) takes care of IP addr 
    initialization problem
    	Bernard Aboba suggest use DHCP auth like ESP in IPsec
    	Question for the IPS WG do we want another protocol at boot
    	How to use IPsec w/o IP address – taken care of in wireless 
    [Chair's note:  While the above content was presented in the boot draft 
    presentation, IPsec deployment in a wireless environment is not as 
    extensive as implied here.  Other security protocols are typically used in 
    conjunction with wireless 802.11x deployments.]
    Bernard Aboba: 
    Resources in boot processes very constrained.
    IPsec in boot PROM is possible, but IKE definitely will not fit.
    DHCP-AUTH probably works, but IPsec with IKE probably doesn’t.
    Need to consider a staged approach. IPsec is reasonable at stage two.
    Recommendation from presentation:
    Boot stage:  Use IPsec
    Not allowed:
    Pre-shared keys (dynamic IP addresses)
    Aboba suggest handling like iSCSI (aggressive mode)
    	Public keys (disallowed by IPS Security draft)
    	Manual Keying (provisioning hassle)
    Corrections to slide:
    Pre-shared keys are allowed.
    Public key encryption mechanisms for IKE authentication is disallowed by IPS 
    security draft, but use of public key digital signatures is allowed.
    If someone is really interested in security, they want it all the way down to 
    level zero boot.
    How do we integrate security mechanisms in the boot loader?
    Not every mode of operation needs to be secure, but at least one mode does 
    need to be secure.  
    Verification of boot image is very difficult.  
    DHCP-Auth makes sense, at boot, security depends on site security usage.  If 
    the second stage boot requires IPSEC, then the adapter better have that 
    ability available. Need to be able to ‘tickle’ the IPsec 
    functionality on the hardware.  
    Big concern is that the Key probably needs to be in flash… Key exchange may 
    not happen – instead may use manual key for only the boot, and the SA is 
    torn down immediately after booting. There is a basic provisioning 
    problem here.
    Direction for draft -- Two phase process.
    	First:  DHCP with DHCP-auth as necessary. 
    	Second: iSCSI to get boot image.  IPsec used here, with simple key 
    		  Pre-shared keys are better than manual keys, but provisioning 
    		  is the same for both if they are burned into the card.  
    		  Pre-shared allows a session key to be generated so lifetime is 
    Comment by Kevin Gibbons:  iSNS has feature where boot target can be 
    specified.  This is as a addition to SLP.  
    iSCSI naming extension draft
    Presented by Mallikajurn
    The T10 had two votes, the Grand Unified SCSI device name format passed 
    first vote in T10 CAP working group, but was narrowly defeated in 2nd vote at 
    Prior to the first vote, in the T10 CAP WG, the common name format was 
    removed.  The proposal became common identity, but different 
    transports could use different name formats.  The T10 plenary 
    subsequently rejected that revised proposal.  The vote was very close at the 
    plenary, and it is possible that the T10 proposal is not dead, but will be 
    addressed at the May or July T10 meetings.
    The iSCSI naming extension draft does not defined LU name, but Rob 
    Elliot’s T10 proposal requires transports to define the syntax of a 
    logical unit name.
    Direction for draft: Keep it alive here.  Add Rob Elliot's additional 
    requirements in the T10 proposal which requires transports to define 
    syntax of Logical Unit Name.
    SCSI Command Ordering Draft 
    Presented by Mallikajurn
    Motion to accept this as an official working group item.  No 
    Will accept as working group draft.  
    This is an implementer's notes draft.  We can not produce too many such 
    In Vienna will continue discussion and decide if other 
    implementation observations (if any) need to be rolled in, or if this can 
    proceed stand alone.


    SCSI Command ordering & iSCSI
    iSCSI Boot
    iSCSI name extension draft - update