|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] RE: iSCSI: ISIDsUltimately, 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. 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 ... 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). 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.
Home Last updated: Fri Sep 07 13:17:13 2001 6428 messages in chronological order |