Re: iSCSI: New Suggested Wordage to cover TPGTs

[Santosh Rao <santoshr@cup.hp.com>]

Hello,

Thanks for addressing this issue. Some comments inline.

Regards,
Santosh


John Hufferd wrote:
> 
> The Naming and Discovery Team (NDT) and Julian, have had meetings on the
> issue
> of TPGT. These meetings were to address the TPGT issue express on this
> reflector.  The following is the recomendation of the extended NDT:
> 
> In section 4.3 (possibly as the last paragraph on page 63 of rev11) -
> 
> The first Login Response PDU during the Login phase from the iSCSI target
> SHOULD return the TargetPortalGroupTag key that contains the tag value of
> the iSCSI portal group servicing the the Login Request PDU. 

Can we alter the above SHOULD to MUST and remove the sentence below ? Is
there any target out there that will not support the addition of a
network portal into a portal group ? (At least the initial configuration
of a target involves the addition of a portal to a portal group ?)

To reduce options and keep the authentication foolproof, it would be
good to mandate that the targets return their TPGT. Not doing so will
expose initiators to the whims of the target implementation.

The authentication is desired by the initiating side and it must have
control over the ability to authenticate. Hence, if we cannot mandate
that targets always send their TPGT in login response, one of the below
2 approaches are possible alternatives, which give the initiator control
over the authentication :

1) Initiators that are interested in authentication send a 
TargetPortalGroupTag=?
in their login request to query the target for its TPGT and authenticate
the response. Target MUST respond with the current TPGT for that network
portal.

2) Initiators send the intended destination TPGT as a part of the login
request and the target MUST authenticate the intended TPGT with the
current TPGT. On an authentication failure, target MUST reject the
login.

Both of the above alternatives allow the initiator to ensure that
authentication is performed, instead of depending on the target to
support sending its TPGT in the login response.

> If the iSCSI
> target implementation supports altering the portal group configuration
> (including adding, deleting, and swapping of portals in a portal group), it
> MUST return the TargetPortalGroupTag key carrying the tag value of the
> servicing portal group. 


> If the reconfiguration of iSCSI portal groups is a
> concern in a given environment, the iSCSI initiator MUST use this key to
> ascertain that it had indeed initiated the Login phase with the intended
> target portal group.

To reduce options and keep the authentication process foolproof, suggest
making this authentication un-conditional. i.e. Remove "If the
reconfiguration of iSCSI portal groups is a concern in a given
environment,"


> 
> In chapter 11 (possibly as section 11.5) -
> 
> 11.5  TargetPortalGroupTag
> 
> Use: IO by target, Declarative
> Senders: Target
> Scope: SW
> 
> TargetPortalGroupTag=<integer-from-0-to-65535>
> 
> Examples:
> TargetPortalGroupTag=1
> 
> Target portal group tag is a 16-bit integer that uniquely identifies a
> portal group within an iSCSI target node.  This key carries the value of
> the
> tag that is servicing the Login request.  The iSCSI target returns this key
> to the initiator in the first Login Response PDU.
> For the complete usage expectations of this key, refer to section 4.3.


-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : santoshr@cup.hp.com
Phone : 408-447-3751
##################################