[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Protocol Action: iSCSI to Proposed Standard
The IESG has approved publishing the following Internet-Draft
as a Proposed Standard:
o iSCSI <draft-ietf-ips-iscsi-20.txt>
This document is the product of the IP Storage Working Group.
The IESG contact persons are Allison Mankin and Scott Bradner.
The Small Computer Systems Interface (SCSI) is a family of
protocols for communicating with I/O devices, especially storage
devices. SCSI is a client-server architecture. The SCSI protocol
has been mapped over various transports, including Parallel SCSI,
IPI, IEEE-1394 (firewire) and Fibre Channel. These transports are
I/O specific and have limited distance capabilities. The iSCSI
protocol defined in draft-ietf-ips-iscsi describes a means of
transporting of the SCSI packets over TCP/IP, providing for an
interoperable solution which can take advantage of existing
Internet infrastructure, Internet management facilities and
address distance limitations. Mapping over TCP ensures that the
high volume storage transfers use congestion control.
Working Group Summary
Special care was taken by the working group in a number of
areas: string comparison (based on Internet stringprep); strong
risk analysis and security; and the SCSI standards. Balance was
needed on each of these and the chairs and working group took
time to get the right details.
The protocol was reviewed for the IESG by Allison Mankin, David
Black, Elizabeth Rodriguez and Bernard Aboba. There are numerous
implementations reported to the Area Directors, including the
RFC Editor Note:
Dear RFC Editor,
Please make the following changes to draft-ietf-ips-iscsi-20.txt -
(1) In Section 8.2.1, replace the following old text at the end of
A single CHAP secret MAY be used for authentication of an individual
initiator to multiple targets. Likewise, a single CHAP secret MAY be
used for authentication of an individual target to multiple
with the following new text:
When an iSCSI initiator or target authenticates itself to
counterparts in multiple administrative domains, it SHOULD use
a different CHAP secret for each administrative domain to avoid
propagating security compromises across domains.
Within a single administrative domain:
- A single CHAP secret MAY be used for authentication of an
initiator to multiple targets.
- A single CHAP secret MAY be used for an authentication of a
target to multiple initiators when the initiators use an
external server (e.g., RADIUS) to verify the target's CHAP
responses and do not know the target's CHAP secret.
If an external response verification server (e.g., RADIUS) is
not used, employing a single CHAP secret for authentication of
a target to multiple initiators requires that all such initiators
know that target secret. Any of these initiators can impersonate
the target to any other such initiator, and compromise of such
an initiator enables an attacker to impersonate the target to
all such initiators. Targets SHOULD use separate CHAP secrets
for authentication to each initiator when such risks are of
concern; in this situation it may be useful to configure a
separate logical iSCSI target with its own iSCSI Node Name for
each initiator or group of initiators among which such
separation is desired.
(2) In both Section 6.5 and 10.14.5, remove the following text near
the end of each section:
UA for the next command on the I_T nexus in cases a), b), and c)
so that the resulting parenthesized comment reads:
(e.g., queued commands and ACA, etc.)
and also add the following sentence to the end of the same paragraph:
In cases a), b), and c), after the tasks are terminated, the
target MUST report a unit attention condition on the next
command processed for each affected I_T_L nexus regardless
of the connection to which that command is allegiant.
These changes are to be made to both Section 6.5 and 10.14.5.