RE: iSCSI: ISIDs

[Black_David@emc.com]

> 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.

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?

> 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
black_david@emc.com       Mobile: +1 (978) 394-7754
---------------------------------------------------