minutes of iSCSI meeting 20 June 2000

[meth@il.ibm.com]

iSCSI design team meeting
Tuesday, 20 June 2000
Haifa, Israel

Attendees:
AA   Alaan Azagury (IBM)
SDG  Steve De Grate (NuSpeed)
JD   John Dowdy (IBM)
RH   Randy Haagens (HP)
GH   Gabi Hecht (Gadzoox)
JH   John Hufferd (IBM)
SL   Steve Legg (IBM)
JM   John Matze (Veritas)
KM   Kalman Meth (IBM)
LDO  Luciano Dalle Ore (Quantumm)
CS   Costa Sapuntzakis (Cisco)
JS   Julian Satran (IBM)
MS   Mark Shrandt (NuSpeed)
PvS  Paul von Stamwitz (Adaptec)
MT   Meir Toledano (IBM)
MW   Matt Wakeley (Agilent)

Disclaimer: Rough paraphrase of some of what was said. Some comments may be
 incorrectly attributed.

Naming

RH - Need to have a better understanding of the SAM-2 naming
KM - Domain names are not necessarily global.
CS- There is nothing better than DNS
JS - Using URL syntax -- does it need to say syntax and semantics
KM - Do we require applications to change since today they do not use URLs.
CS - How to associate in Linus /dev/sdd1 to a specific SCSI device.
This is part of discovery so this is beyond the scope of this document.
RH - Naming is critical to identify third party objects
RH - Use of domain names does not seem  to be controversial.
 The rest of the URL structure might be more debatable (e.g. to identify
LUNs)
CS - Domain names can also directly code an IPv4 and IPv6 address, where
you don't want to require a DNS
RH - Issue with naming LUNs - different users refer to the same LUN using
different names.
Do we need a central authority that will translate names to be able for one
 user to pass a reference to a LUN to a different user.
KM - Using the VPD with the URL gives you a unique identifier to the LUN.
PvS - VPD may refere to a virtual LUN,not a physical device.
Need to make sure that the VPD satisfies our requirements.
JS - Is it too early to resolve, since we don't have a discovery mechanism
in place yet.
We should restrict ourselves to the basic naming service.
JH - An entity could have a unique name based on the domain + VPD.
A directory could translate this name to a human-readbale name.
A host can remap the name to the VPD and map this address to his local LUN
number and access the device through this LUN.
JS - Could we not use the LUN number at all?
JS - Naming allows exporting only the devices that an iSCSI target wants to
 export.
JH - Initiator can query the target what devices are "attached" to it.
The target can return whatever devices the initiator can access.
JS - The current naming mechanism allows different naming for the same
target that allows mapping different
views to the same target.  We should not enter the details of the LUN
naming.
Views are maps to "real" things that the initiator is allowed to see.
LDO - SAM-2 has unfriendly name.  Why are we trying to build a mapping from
 user-friendly names to the SAM-2 names?
Names need to map well onto the SAM-2 naming.
RH - SAM-2 allows dfferent, maybe overlapping views of LUs through
different SDPs.
 These views are defined by the controller.
JH - In FC, the views are defined by initiators (host worldwide name).
 RH- Jim Hafner has "equated" the worldwide name to an accessid.
In this world, the controller does not present different views, but the
view is determined by the accessid.
JS - Do we know enough to name LUs.  Julian thinks not.
RH - We should support the SCSI naming architecture.
LDO - Are we trying to do too much in iSCSI layer?  Should the query of LUN
 0 be left to SCSI?
SC - The URL just identifies the target (with a certain view).
JS - View = Virtual target.  A domain name defines a virtual target.
LDO - Can the name be:  scsi://a.b.c.d/accessid
JS - Acessid has been accepted by FC


Security

LDO - Two security models: (1) authentication/authorization and (2) fully
encrypted link.

(1) is resistent to interception (listener cannot reuse authentication to
authenticate itself).

Use the SCSI access control proposal.  User ID is stored in the access
control database.
Security key is to be stored in a parallel db using a separate exchange
protocol.

CS - Can many machines/processses have the same user id.

LDO - Can the User ID correspond to AccessID?

RH - Do we want to separate principals and views?

CS - What is the scope of the AccessID?  Host/Target? Only host?

CS - scsi:/a.b.c.d/cdrom -> cdrom is the target, not the accessid.

JS - We are talking about authenticating machines, not "users".

PvS - The Hafner proposal assumes a trusted environment.

LDO - Until there is a good reason, we will assume that user id and access
id is the same.

SC - Access ids allow you to have different views within a SDP (target).
You can also use different targets (SDPs) to present different views.

SC - a tuple (domain_name/path, accessid) defines the actual view.



Lunch



LDO: Have User id (== access id). SCSI doesn't provide place to save this
info.
So we'll need a separate database for these.

LDO continues presentation:

Fully Encrypted Link
----------------------
Use IPSec as security mechanism
     use Login with null authentication scheme -
          use IPSec authentication
Discard SSL
     IPSec better hardware support
     possible use of SSL on Internet?

Challenge by JH.
LDO: At present, we don't see a good reason to use SSL vs IPSec.

CS: Let's write down on the board the advantages and disadvantages of each.

IPSec:
+ simplet hardware
? requires an IPSec supportive TCP stack.
- no App API for key mgmt.
+ more secure (no TCP DOS)
- NAT boxes don't exist yet.
+ hardware support readily available
? it encrypts everything above the IP layer. all or none


SSL
+ APP layer library (rapid deployment)
- APP layer library (not easily available in kernel)
+ mature
+ goes wherever internet goes
- lower bandwidth? (due to lack of current hardware support)
+ internet

JS: Now that IPSec is included in Windows 2000, it is available enough.

CS: IPSec doesn't work so well through firewalls, whereas SSL works fine.

Once we decide what we want, we could probably get either one in hardware.

RH: IPSec will make it worse for my Traffic Monitoring software.

LDO: That's why you do encryption!

Discussion on what happens in NAT box and why IPSec won't work with it,
since the checksum is
encrypted and the NAT tries to change an IP address, thereby requiring
changing the encrypted checksum.

JS: It is reasonable to say that use either IPSec or the data will have to
be encrypted at the storage level.

If you have a VPN, then no need to impose another level of security.

SSL (in the short term) is going everywhere the internet goes; it will be
more widely deployed.

LDO: SSL is currently very tied into html.

JH: IPSec will work with lot's of protocols. Will SSL work with so many?

JH: If we choose SSL, then vendors will support it in hardware, so there
won't be lower bandwidth for SSL.

LDO: We should put this question out to the Security community.

LDO: Most people won't use security unless they are big companies.
So we should look at what big companies are going to use.

RH:And most big companies are going to use IPSec infrastructures.

CS: IPSec is not quite mature yet.

LDO: What about in 2 years time?

PvS: Who is going to ask for block storage over the internet?
What applications are going to use this? Then choose SSL or IPSec depending
 on which is more appropriate for the application.

JS: We don't want to choose one method that may not be accepted by the
broader community in n years time.

LDO: Essentially we are saying that we will support both.

KM: A target MAY support one or the other or both. If a connection comes in
 and tries to talk IPSec,
the target can reject the request and insist on the other.

JH: If a vendor comes to you and asks which one you want implemented in
hardware, what do we tell him?

RH: We will figure out what we need to put into iSCSI to support both.
JS: And then we'll see the mechanics to see which one is more apropriate.
RH: So what commands do we need in iSCSI to use IPSec and/or SSL.

LDO: Use your identity for IPSec as your name for iSCSI, and then iSCSI
simply needs to pass this name
to the IPSec layer to perform the authentication.

JH: How does this now connect with out discussion on AccessId?

RH: Can you please give an explanation of how IPSec comes up?

LDO: In IPSec one of the authentication parameters is the user id from the
operating system.

JH: We can make it our Access id.

LDO: We can try to define it later... we think there is a way to implement
it.

LDO: There is also a security descriptor.

LDO: Fundamental question: does IPSec allow you to use a user id as
authentication?

JS: Win2K allows configuring IPSec for all TCP/IP connections: it allows
configuring for Server request,
client (respond only), secure server etc.

KM: When do you set the IPSec connection, does it need to be called by
application or is it at the IP level?

LDO: It depends how you implement the protocol stack on the machine.

KM: The application has no control of whether to use IPSec.

JS: The only thing that can be done is to set a policy.

KM: iSCSI has no code to write to use IPSec.

JS: Let's go through the mechanisms and then come back to this issue.

LDO: If we use IPSec, we use the access id as the user id.

RH: The PAM guys might not agree to use the access id as the IPSec user id.

LDO:  Do we need a separate port for SSL?

KM: We can do by trial and failure:  if the SSL handshake fails, we can
retry with non-SSL

LDO: (1) iSCSI negotiation to start SSL, (2) SSL negotiation, (3)encrypted
iSCSI

LDO: In http, there are two different ports.

JS: How will the mechanism work at login?

LDO: Two options: (1) single port and need to upgrade to SSL; (2) two
ports.

LDO: Need to specify the interaction (user id vs access id)

JS: IPSec requires an administration server.  We need to answer  those
questions.

LDO: SSL provides encryption and authentication of the server.

CS: SSL provides the means also to authenticate the client to the server
(client certificates).

CS: Do we need to spec at least two security mechanisms?

LDO: Do we all agree that we do IPSec and SSL.

KM: Do we need to authenticate as part of the login?

LDO: In SSL you need it if you are not using client certificates.

LDO: If we only want authentication, we do not want to require encryption.

JS: Challenge/response is good enough for authentication?

All agree

JS: For Pittsburgh we need the draft ready in 2 weeks.

RH: Are the secuirty models mutually exclusive
     0. No security - generic login with ACL
     0.5. Login name + password (clear)
     1. challenge/response authentication
     2a. IP Sec.  IP sec authentication is used
     2b. SSL - authentication thru client certificates; privacy + 1.

CS: Challenge/response is very easy to implement.  We should require it
instead of 0.5.
 Doesn't like to send password in the clear.

JM: It becomes an administrator headache.  No security is not enough.

CS: Most recent CIFS does 1.

JM: Agrees to drop requirement for 0.5.

LDO: IPSec is more adequate for enterprise; SSL is more adequate for
Internet.

JH: When going thru NAT you probably do not want to use IPSec.

JM. In what environments do you need 2?

CS: Marketing guys said do not release this without security.

JS: SSL suits short-lived transactions.  IPSec can live with long
transaction, change keys regularly.
Julian bets that IPsec is the right approach.

JS: Do we need any security hardware in the adaptor?  If we need something,
 it is probably IPSec.

CS: SSL allows to  renegotiate keys.

RH: IPsec runs on the network... Network administrators prefer it because
they are "securing the network".

JH: Is it sufficient to say 0, 1 and 2.b?  2a is implicit and should not
concern iSCSI.

RH: Does not agree.

JM: CIFS uses 0, 1 and 2b.



Requirements (pass 2)

PvS: Do not need an exclusivity statement that this runs only on TCP.

RH: Non-goal: iSCSI does not need to run on anything other than TCP.

JS: Reliable, in-order delivery and congestion control are the minimal
requirements of the transport.

JS: About 3.2, the number of 100 microsecond is not too realistic.  Replace
 with delay can be significant.

SL: Reinforce that not more than one interrupt is required per I/O
operation

JS: Regarding low delay, add "we will handle well infrastructures that have
 a good bandwith-latency product."

CS: Are there any implications on the implementation on cost
comptetiveness.

JS: The fact that we did not consider implmeneting FCP on top of IP.

PvS:  Will any SCSI "drive" need to export a LUN 0?

RH: Including good support for individual disk might imply significant
simplifications in iSCSI.

MW: What part of FC will hijack ...

MW: Need to require that this runs on reliable protocol

CS: Support SCSI SMA-2 architecture: add "where it is applicable"

KM: Is task queuing a requirement?

PvS: We need to make it a requirement.

KM: Can't assume it supports task queueing just because it runs on top of
iSCSI.

PvS: Could require task queueing, but specify max tags is 1.

MT: SCSI3 compatibility -- what about CAM?

KM: Why do we need the "forward compatibility" requirement?

RH: The main point is to have clean layering.

JH&PvS: Isn't that already included in SAM? So we can drop this
requirement.

RH:

MS: We can never cover ourselves from all possible evolutions of SAM.
This statement should move to a Front Matter section.

MT: If you say SPC-2, then you should also list other similar protocols.

MW: FCP needs (FCP-CONF) confirmation only for error reovery.
For TCP we shouldn't need this.

RH: We'll remove this from the requirements, but keep it in mind for
implementation.

KM: Do we want to require that iSCSI can be used for a gateway between FCP
networks?
Might we not be somewhat dependent on FCP to be able to run over iSCSI?

JH&RH: Without this kind of gateway, iSCSI won't sell.
We absolutely need this to be achievable by iSCSI.

KM: Do we want to make this a requirement on ourselves? or simply state it
as a goal?

.......

----------------------------------------------------------



command protocol -> command sets

----------

Topic: Requirements opoint on translating gateways

Add that we think it's redundant but we'd like to call it out

CS: Process check
    How do we speed this process up?

Options:
Just raise issues explicitly
Going through it one-by-one was valuable

Next hour we'll raise issues explicitly


Clarification of 3.4.1 - doesn't preclude trunking

Point 3.4.3 brings up ordering of commands per LUN or ordering of commands
per session?

MW - reorder requirements - second before the first one

RH - does anybody disagree with 3.4.3?
CS - No. It basically says that you support SCSI queuing

JH - In the wide area, a method of pipelining commands and responses
is required

CS - the requirement is more complex than saying you just support
SCSI queing.

RH - delivering commands in order never hurts

MT - Why keep order between logical units in commands?

RH - SAM-2 does not require order between LUNs. However, it may make
target implemetnation easier.

------------------

JH - why do we require that pipeline commands and responses?

RH - change required -> needed

---------

3.5.1 agreed
3.5.2. agreed
3.5.3. Strike we reject the idea...

Hufferd - how could the storage not respect bandwidth management
or congestion avoidance algorithms?

RH - By not using TCP

MW - Are we going to say anythign about IPv6?

CS - Definitely, we should say we support it.

RH - Should we require that implemetntaions hafve dual stack?

CS - No. Just the protocol should support it.

MW - You don't mention the IPv6 literal naming in the iSCSI spec

3.5.4 Link indpendent
3.5.5 LAN, MAN, WAN capable

RH - mention insufficient memory for spanning large distances
LO - it might degrade performance, but it doesn' tlimit capability

CS - Other aspect of this is firewalls and NAT. This is common in
WAN
RH - we need to think of these things in the WAN.

Agreed

3.5.6 Framing - some method iSCSI protocol units within the TCP
stream must be defined

RH - this might not need to be here. It has to know when an iSCSI
protcol unit starts. The transmitter must ensure that it gets
transmitted and not buffered.

LO - buffering is a specific TCP implementation and not a generic
problem

JVeritas -


RH - how do we establish frame syncrhonization?

LO - we can ignroe this
JC - TCP is a stream of bytes

RH - it just comes as a byte range. How does it identify?

LO - never make a mistake.
MW - Proper message forming not just parsing

RH - framing issue and pushing issue
   - connections are long-lived
   - cumulative effect of length fields

LO - overwritten by CRC
   - any error in synchronization is major


RH - badly formed packets due to software error
Answers - should fail checksum

RH - target fibrechannel should be robust against anything sent

MW - can somebody jam data into somebody's TCP connection?

Answer - yes...

LO - CRC is sufficient

RH - number of techniques one uses for reliablity. Framing of packets
   - length fields
   - most robust systems use several techniques (SOF, CRCs, length field)

   - could compensate for TCP's lack of framing

LO - known bit-error rate of TCP is ...

RH - mainly worried about software and hardware problems
   - don't know what errors we're open to when we're relying
     on stuff from time 0

LO - use flag byte at beginning of packet

RH - same as byte stuffing?

LO - this is just error detection

JH - CRC strength is not strong enough
   - recommendation was to use another CRC
   - use the CRC stuff we actually use on the disk

JVeritas - CRC is overkill

JH - stronger thing that can be used

MW - where are you going to drop the bits
   - covered by 32 bit CRC


CRC discussion
--------------

MW - TCP checksum and MAC layer doesn't fix PCI

CS - can be fixed with end-to-end CRCs



JS - any decent storage system is end-to-end

   - only do it in two says (SCSI/iSCSI layer)
            - could protect against errors in protocol stack
         - could protect against erros in PCI

   - do it in TCP stack
         - could protect against errors in TCP segments

MW - solving the problem halfway
   - TCP checksum doesn't deal with stuff at higher layer


RH - this end-to-end principle
          - recovery should be done at highest layer (most correct)
          - put stuff lower in the stack for optimization purposes only

JH - protected against most probably problems
   - high value in and of itself

LO - verify framing by putting a well known bytes
   - at the beginning of each packet
   -


------------

Large discussion on iSCSI framing and CRCs

Main issues on CRCs and reliability
   - Do nothing
   - TCP-layer CRC (CRC on datagram)
   - iSCSI layer CRC

Higher layer CRCs were seen as being able to detect the most
kinds of errors. However,

The iSCSI layer CRC was proposed in a couple different forms:
covering iSCSI messages, every n kilobytes in the iSCSI stream,
or covering only iSCSI data.

LO pointed out that IPSec provides a very strong CRC with its
authentication header  (MD5 checksum). A well-known key (say 0)
could be used to avoid the need to do key exchange for
authentication.

Consensus: IPSec AH for extra integrity

------

Some discussion on having the common cases in iSCSI being that
1 TCP segment contains an iSCSI message as payload (optimization).
This would be especially valuable for data transfers, as
each segment would have enough information to place the data
in memory at the remote end.