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.
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 (email@example.com)
Fibre Channel (FC-2) over IP: Murali Rajagopal (firstname.lastname@example.org)
iFCP: Franco Travostino (email@example.com)
|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|
|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|
|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.|
Current Meeting Report
IETF IPS Meeting Minutes
December 10, 2001
Reference section in all documents must be split into two sections normative and non-normative.
Interim meeting in Feb. Announcement on IPS mailing list & IETF announce. Need RSVPs.
Information at www.ietf.org/IESG/IPS-Interim.txt
-- FC Encapsulation draft (Ralph Weber)
SOFc4 will be going in, other minor (editorial) fixes.
Rev 5 will be candidate for last call.
Last call will be in conjunction with FCIP and/or iFCP
-- Security draft (Bernard Aboba)
Security document will go standards track, but all protocol docs will be self contained.
Protocol documents will govern, in case of any discrepancies.
Note to this effect will be added to security draft.
Cannot require sequence space extension is in ESPv3, since will not be available for some time.
NAT traversal language will be non-normative due to IPR issues and problems encountered in testing IPsec NAT traversal.
- Protocol specs, need SLPv2 security update (2608bis), but may be able to finesse needing a normative reference
- IPsec transforms are in progress.
See IPsec WG for more, for the AES drafts, MAC is in good shape,
CTR requires some attention in ipsec WG
- SRP (RFC 2945)
- DHCP-ipsec drafts.
Must: 3DES-CBC; HMAC-SHA1
Should NOT: DES
Should: AES-CTR and CBC-MAC w/ XCBC
Q: (William Dixon) Ė Why not AES-128CBC instead of AES-CTR? Much further along;
interoperable implementations are available. Will be discussed in ipsec wg.
Resolving issues off of the mailing list.
Demoting 3DES will cause interoperability problems.
Transport vs. Tunnel mode
Specified: iFCP, FCIP Tunnel mode MUST; transport MAY
iSCSI, under discussion.
Summary of pros/cons
- Pros: End to end security, Lower overhead, Larger MTU,
Negotiation of connection specific selectors is common practice
- Cons: Requires ipsec to be implemented on the IPS entities
Greater difficulties with NAT traversal
- Pros: More compatible with existing VPN gateways,
Donít have to implement ipsec on IPS entity
Easier to traverse NATs
- Cons: More overhead, Smaller MTU
Tunnel problems - connection-specific selectors and dynamically assigned addresses (problem is use of mode config which is non-standard - standards track documents exist, but not clear whether they will be widely implemented).
Tunnel mode + connection-specific selectors are very difficult to do.
Many gateways do not do connection-specific selectors well.
Need to look at these issues in more detail. Implementors please look into the security gateways you're planning to use.
Both Main and Aggressive are MUST, Aggressive mode is there to deal with dynamic addresses.
Open issues in use of specific ID types.
- Constraining IKE is a good first step.
- Security policy gets tricky when
- Not all nodes in an iSCSI network support security
- IKE times out when trying to reach a non-IPsec entity
(e.g., 60 sec). Initiator needs to know whether to try IPsec or not to avoid this.
Responder-controlled security [TCP SYN in clear, target sets up an SA if it supports IPsec] is an alternative. Currently a MUST NOT to avoid denial of service issues because TCP
SYN causes IKE work (much worse than TCP SYN flood case).
This limits need for security policy to target.
Doesn't work well for target initiating IKE to initiator behind a firewall or NAT.
- May use iSNS security policy distribution.
- Existing IPsec policy distribution mechanisms have been problematic.
iSNS could be better.
SHOULD: use IKE certificates
SHOULD: check certificate revocation list
MAY: use certificates to determine authorization
Easiest enrollment solution is to have HBAs get/use host certs.
Long cert chains cause IP fragmentation in IKE, which can cause problems.
Allow any IKE certificate - use these for identity only, avoid adding new OIDs to do iSCSI authorization.
General, but inconclusive transport vs. tunnel mode discussion.
Pros and Cons for making each the MUST implement brought up.
Neither mode will be prohibited. Can make both MUST, but decision has not been made.
John Hufferd asks about transport vs. tunnel mode resolution
Needs to go to mailing list
David Black will write something up.
-- iFCP (Charles Monia)
- iFCP N_Port address definition
Currently IP address of gateway + N port ID behind it. Issue with NAPTs.
As of -08, adding TCP port to IP address (gateway address is the pair).
No iSNS change required.
- FC Broadcast
FC Broadcast is best-effort, IPFC and FC-VI use this to do discovery.
Not performance-critical. Currently uses UDP/IP, may not be as reliable as FC broadcast over fabric, and relying on IP fragmentation may be a big problem. Changing to a server-based TCP implementation of broadcast - send broadcast frame to broadcast server who then sends it to all gateways.
Use 0xFF-FF-FF well known address as port ID for all of the iFCP entities involved in this. Discovery based on iSNS - need iSNS changes for this.
Need to look at issue of two broadcast servers in the same domain.
- Stale Frame detection
Currently optional. Will change to MUST implement and MUST use.
-- iFCP MIB (Charles Monia)
Minor changes, cleanup from review by Keith. Fairly stable, close to done.
-- iSNS (Josh Tseng)
- Change to support iFCP transparent mode.
- Security Issues. Use IPsec to protect iSNS messages.
MUST implement IPsec w/ESP in tunnel mode for iFCP and appropriate mode for iSCSI.
Use unicast for query and response message
Use multicast for iSNS heartbeat used to discover iSNS server
iFCP gateways and iSCSI devices using iSNS SHOULD authenticate to the iSNS server.
- Use of iSNS to distribute security policy
This is about centralization of security administration.
Security bitmap to hold things not already negotiated by ISAKMP.
Parameters to be stored and distributed by iSNS - Use/non-use of: IPsec, IKE, Main Mode, Aggressive Mode, Perfect forward secrecy, preshared key, tunnel & transport mode.
Need to review this for what's necessary - work with security draft authors (e.g., Bernard Aboba).
- DHCP option - make absolutely sure that a new one is needed before asking for one. DHCP name server option may not be appropriate (RFC 2937).
-- iSNS MIB
No serious content changes - minor cleanups (similar to iFCP MIB), stable, close to done.
-- FCIP (Ralph Weber)
At -07 draft. Major open issue is WWN short frame security. A few other minor changes will be made (e.g., add SOF and EOF for class 4 FC service).
WWN Short Frame Security
- Prior to Irvine, FCIP endpoint was IP address. NAT/NAPT support makes this problematic. Sending WWN across as identity.
Discussion of how to go about solving this problem - authors would like to do this as part of FC-BB-2 rather than FCIP. IETF IPS oversight/check of this will be necessary. Since FC does not have the concept of multiple switch-to-switch links between the same pair of switches over a single cable, an FC-BB-2 solution is more appropriate than a generic FC solution. Expect to see proposal on list soon, discussion at FC-BB-2 in Feb. and IPS interim that week.
-- FCIP SLP
No known issues aside from coordination with security draft updates. Will revise to match those and be ready for WG Last Call. FCIP-SLP draft tracks security draft which tracks 2608bis.
-- SCSI, FC Mgmt, and FCIP MIBs (Keith McCloghrie)
FC Mgmt MIB has been transferred to IPS from IPFC. Keith is rearchitecting (e.g., consistency with IF and Entity MIBs, remove non-FC objects), expect first ietf-ips-fcmgmt-mib draft soon.
SCSI MIB - design team nearing completion of UML model. Internet-Draft will be forthcoming shortly. T10 working session on SCSI MIB on Monday, Jan 14 in Houston. Details available at www.t10.org/meeting.htm.
FCIP MIB - There are a bunch of work items - NAT, BB-2 changes, dependent on rework of FC Mgmt MIB.
Yaron Lederman: SCSI and iSCSI MIBs use "instance" abstraction so that one MIB can represent multiple entities, FCIP should do likewise.
Security - SNMPv3 has security. Get security boilerplate from IETF OPS MIB site, and expand on it to add specific information about risks involved in specific writable elements. DO NOT say "MUST use SNMPv3".
Next draft will be coming in January.
End discussion of transport/tunnel mode and related issues.
Dynamic address support for tunnel mode is an interoperability issue that weighs against use of tunnel mode.
---------- Tuesday Dec 11---------
-- Agenda rebashing
Framing requirements agenda item pulled due to Transport AD/tsvwg issue. Resolution will be posted to the list (resolution was that the tswvg tcpulpframe draft will become an experimental RFC, and hence cannot be REQUIRED or RECOMMENDED by iSCSI - see list for further discussion.
-- SRP IPR requirements (David Black)
Note Well statement displayed.
If know about IP, need to disclose. Further, if you should know about IP, need to disclose (e.g. Company cannot keep you in the dark in order to avoid disclosure). But, no patent search is required (e.g. if no way you should know, don't need to go out of your way to find out if there are claims).
Should company own IP directly material to standard, IETF will ask Company to publish statement, and request fair, reasonable and non-discriminatory terms for licensing of IP.
Company is not obligated to comply.
IETF does not judge fairness
Claims (rumors) against SRP
1) Stanford. Royalty free license available.
2) Lucent. May have IP that may be essential. If essential, will be licensed under standard Lucent IP licensing practices.
3) Speke patent. No statement. May be owned by Phoenix Technologies.
MUST/SHOULD/MAY requirements discussion for SRP at February interim meeting.
Closing warning from AD and WG chair about results of Dell and Rambus situations in which hiding patents resulted in patents being unenforceable (FTC consent decree for Dell, actual court decisions in Rambus).
-- UNH Plugfest report (Yamini Shastry)
Held Oct 28 - Nov 3
Based on -08 draft
15 participated. 4 initiators, 1 initiator, 9 both initiator & target. 1 neither initiator/target.
Reserved bits test did not match with "MUST be zero on transmit/MUST be ignored on receive"
Summary of changes made to draft as a result of plugfest - most are minor, see slides.
OOO issue is number 5 on this list - will come up in main iSCSI section.
Areas not tested include
- multiple connections/session
- discovery sessions
- unsolicited and/or immediate data
- command windows greater than 1
- No implementations of markers
- No real error recovery
- No serious parameter negotiation beyond defaults
Next plugfest [Feb 11-15] will look at these areas. Based on -09 draft.
Information from www.iol.unh.edu or from Yamini at firstname.lastname@example.org.
New scripts will be available 2 weeks prior to plugfest.
Request to state minimum conformance required for products to participate made.
Markers - determining whether they're in/out has to wait for resolution of status of tsvwg ULP Framing draft.
-- iSCSI (Julian Satran)
- Security (tunnel vs. transport, and transforms)
- Framing (tsvwg status)?
- Constant overhead word stuffing (version of Constant Overhead Byte Stuffing) as a possible alternative
- Abort Task Set/Clear Task Set
- OOO PDU handling
- Serious issue: are NOPs allowed in a discovery session.
* Abort and Clear Task set
- Remove ordering discussion for Clear Task Set
- Abort Task Set currently requires a SCSI response for every aborted command. Alternate - hold Abort Task Set response until all outstanding responses are ACKed by the initiator.
Avoids any need to create "fake" SCSI responses, significantly reduces burden on Initiator. This is slower, but much simpler.
Most of section 9.4 will vanish.
Sense of the room - follow this approach, modulo working out details on the list.
* Out of Order Operation
- This is a within-connection issue. No ordering requirements across connections.
- Within-connection issue turned up on list in context of allowing a DMA engine to reorder commands at its convenience. Could use multiple connections to do this.
Eddy Q: DMA flow-through to wire is a plausible adapter design that increases the desireability of doing ordering.
Mallikarjun: Unsolicited non-immediate data provides additional ordering flexibility.
Sense of the room - this is the right approach.
* NOP in Discovery Sessions
Underlying problem is whether to keep discovery session around for detection/notification of configuration changes.
Mark Bakke: Want to know when new targets become available. Multiple ways to do this. Discovery session is an in-band way of doing this, allows an async message to be sent to do this (won't need to poll). Wants both NOPs and async messages on on discovery session to keep it alive long-term.
Resolution - N&D team to generate text describing applicability and use of the various mechanisms, along with requirements on implementations to yield interoperability. Will ship to list and use that to drive closure on need for long-lived discovery sessions which in turn will drive closure of NOP issues.
Word-stuffing version of COBS is an alternative to markers. Has to touch every byte of message. CRC and ESP also have to, so this might be a good alternative when those techniques are in use.
COBS/COWS is the same class of mechanism as markers, similar considerations.
Comment that something is needed that doesn't require TCP modifications - that would be either markers or COBS/COWS. Hardware targets talking to software initiators is the scenario of interest.
Comment that TCP modification for framing is acceptable, hence no need for COBS/COWS or markers.
Discussion is not conclusive - Need to get tsvwg ULP issue resolved, write COBS/COWS up in detail (sense of room is no serious objection to doing so), and take this up on list, resolve at Feb. interim.
The -10 version will appear sufficiently prior to interim meeting.
-- iSCSI Boot draft
iSCSI usage of DHCP option is fine. Will go into next draft.
(DHC WG consulted, no need for DHC draft).
-- iSCSI Naming and Discovery
Will be informational.
IQN format will use date codes
New ISID format
New username and Initiator name usage guidelines
Stringprep approach to character normalization
ISID format change - ISID will contain vendor ID. Will now be 48 bits, use
IEEE OUI or IANA OUI. 02 should be "Local Usage" rather than "Random".
Note that this can be coped with at install time.
3 forms now acceptable
1) IEEE OUI
2) IANA Enterprise Number
3) Vendor unique -- locally unique; not globally unique.
Recommendation: Double size to 128, so that you can have a WW unique value
Response: Not needed -- ISID is relative to iSCSI node name, which is WW unique.
Three people support embedding the MAC into the ISID. Will take this to the list.
John Hufferd: Embedding the MAC in this ISID binds the session to a single HBA.
Conservative Reuse description. Reuse ISIDs across all targets. Needed to deal with T10 changes in progress to persistent reservations.
-- Stringprep (Mark Bakke)
IDN is close to done on the stringprep/nameprep drafts. This draft is about how to use this for iSCSI names.
Q: What about unassigned codepoints.
A: Whatever underlying stringprep draft does.
Sense of room: adopted as WG draft.
-- SLP for iSCSI
Document is stable, unicast SLP usage is ok.
Will coordinate security w/IPS Security draft.
Will work with SLP authors on suitable notification support.
-- iSCSI MIB status (Mark Bakke)
Fitting into family of MIBs below SCSI MIB that is being developed - FCP MIB may be developed, no plans for parallel SCSI MIB. Details of how these fit together being worked out in SCSI MIB team.
Will be looking at how to add usernames/cert identities to access control area of iSCSI MIB w/o large complexity.
-- iSNS for iSSI status (Josh Tseng)
See iSNS session on Monday. New informational material on how iSNS can be used to map iSCSI and FC devices in a hybrid installation.
- Request to look at applying ISID-like structure to portal group tags for consistency and autoconfiguration reasons.
IP Storage Security
SRP Intellectual Property Rights
iSCSI - a SCSI over TCP mapping
Status of iSCSI Boot
iSCSI Plugfest (Oct 28 - Nov 3) UNH InterOperability Laboratory
FC Encapsulation Status
iFCP MIB Status
iFCP Issues from 11/20/2001 Review
iSNS MIB -01 Status
FC Management MIB
SRP Intellectual Property Rights
iSCSI - a SCSI over TCP mapping
Status of iSCSI Boot
iSCSI Plugfest (Oct 28 - Nov 3) UNH InterOperability Laboratory