Subject: Re: iSCSI: ISIDs

From: Sandeep Joshi <[email-masked]>
Date: Fri, 07 Sep 2001 14:27:00 -0400

David,

[email-masked] wrote:
> This is primarily an issue for recovery of session-associated resources
> like Persistent Reserves.  There's no free lunch here - it's necessary
> to remember where these were put (which session) in order to get them
> back.  It can also help to get old sessions removed from the Target
> faster.  If the initiators remember TSIDs, this all works - is there
> an important difference for implementations in remembering dynamically
> assigned TSIDs vs. statically assigned ISID ranges?

You have tackled every question except the one you have raised 
here and in a previous email :-)

..Is it a big difference for the initiator to remember a
dynamically assigned ID ?

Most hardware-based HBAs should have probed the network
and discovered existing targets before the OS does its SCSI scan.
In which case the HBA would have some persistent on-board memory
as it cannot expect the OS to provide the ISIDs from
some file or registry _before_ the SCSI scan.  Hence I dont see
a problem with the hardware-based HBA remembering an ID.

As regards software-based initiators, they would be expected
to initialize only after the OS (partly) initializes in which 
case they would have access to some "file" which could contain 
the IDs.

I may be wrong here..but this point deserves some discussion from
the people with cross-OS expertise if we are to go with 
target-assigned IDs scheme.

thanks
-Sandeep

---

From: [email-masked]
Date: Fri, 7 Sep 2001 13:30:26 -0400

> Ultimately, the detection of duplicate sessions has to occur on the
target.
> If we are not expecting initiators to retain the TSID (target assigned
SID)
> of any sort between reboots, then something totally initiator based may be
> the only fit.

> The recurring theme here is how to authenticate the passed
> ISID & TSID.  What prevents HBA-B from saying it's HBA-A (or however you
> want to word it)?  Putting session identification into the authentication
> exchange (and NOT the login header) may be the only way to guarantee
> detecting imposters.  If you want to guarantee security along with
recovery,
> I think this would be the better place to begin.

This is seriously off-topic.  There already is authentication in the
login exchange which if used must complete before any damage is done to an
existing session, and there's also IKE authentication at the IP level.
In other words, the existing iSCSI draft specification already addresses
this problem.

> It appears as though SID needs to act more like the Ethernet MAC address.
> We want something that uniquely identifies the initiator whenever it logs
> into a target (something larger than 16 bits).  This moves more towards
> Marjorie's position that session identification should be pre-assigned to
> initiators through configuration:
> 
> 	... an iSCSI HBA will have to have a configuration interface,
> 	supplied by the manufacturer, in order to be installed ...

If it has to be globally unique, it's going to need at least 64 bits.
Global uniqueness is currently a function assigned to the iSCSI
Initiator and Target names.  Duplicating it in session identifiers
is almost certainly a mistake.

> I'm a little skeptical about the dual use of InitiatorName as part of the
> session identification.  What prevents a pool of servers from sharing the
> same user account credentials (which may be useful in reducing
> administration overhead).

This is why the UserID (for iSCSI authentication) is separate from the
iSCSI Initiator Name.  One can share the UserID and associated account
credentials across the servers but use a different iSCSI Initiator Name
on each.

> It's unlikely that a group of Servers would ever
> want to share the same session.  Something like "SessionId=" that is
> pre-configured on each initiator might work better.

Separate iSCSI Initiator Names should be used for this case.

Thanks,
--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140     FAX: +1 (508) 497-8500
[email-masked]       Mobile: +1 (978) 394-7754
---------------------------------------------------