Final London Minutes

[Black_David@emc.com]

A big "THANKS!" to Michael Smith from iReady for transcribing
the missing pieces of the draft minutes from his recordings.
A bunch of important pieces were filled in as a result.

--David

IP Storage (IPS) Working Group
Minutes of 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 focused 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?
	A: Initiator can do what it wants unless DataSequenceOrder=yes
(default),
		since the target can not go back in the data stream to fetch
missing
		data.  A "Not enough unsolicited data" is being added for
this situation.

Open Issue - Simplification of Login.  Separate security sub-phase,
OpParamReset.
	Can operational parameters be exchanged before security phase?

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:  (1) SecurityContextComplete by itself in message
exchange.
		         (2) Should always have a security exchange.
                     (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 confidentiality 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 different situations, hence both are in the
	tsvwg draft.  Common interface to both mechanisms.

iSCSI recommendations:
	- Remove marker annex and refer to tsvwg draft
	- Define negotiation for PDU alignment
	- Strongly encourage PDU alignment implementation (SHOULD).

Summary of proposal on what iSCSI should require for framing:
	- Receivers can do nothing, PDU alignment, or all 3.  Marker impl.
requires
		PDU alignment framing.
	- Senders should implement all 3, MUST implement markers.

	These don't match because want receivers to call the shots.  Markers
are
	easy to implement on send, hard to implement on receive.  There were
no
	marker implementations at the plugfest.

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:
	- Header and Data digests
	- SNACK
	- Recovery R2T (negotiable)
	- Unsolicited NOP-IN (e.g., sequence fixup)
	- Retry (command replay, failover, and hole-plugging)

Topic 1: SNACK issues (slide 8)  Alternatives
	- Assign a CmdSN (deadlock issues)
	- Accept non-determinism [e.g., lost SNACK] (odds of loss are low)
	- Allow SNACK retransmit (may get data retransmit)
	- Define timer-based SNACK retransmit (Ouch!)
	- Drop SNACK
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.
	Number of levels and order thereof to be worked out on list.

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:
	- Remove P bit.  If there's data, DataSegment length indicates.
	- If task tag is valid, response is required (ITT valid = Initiator
		wants answer, TTT valid = Target wants answer, NOP-In cannot
		have both tags valid).
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.
	Two choices:
	- Enterprise Number
	- Date (yyyy-mm)

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.
	Details to be worked out and posted to list.

Case Sensitivity
	- Currently case-sensitive.  Now recommend NAMEPREP
case-insensitivity,
	draft-ietf-idn-nameprep-05.txt.  Use NAMEPREP in admin tools,
byte-wise
	compare in implementations.

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.