RE: iSCSI: reusing ISID for recovery

["KRUEGER,MARJORIE (HP-Roseville,ex1)" <marjorie_krueger@hp.com>]

I am opposed to doing anything before authentication as this opens
opportunities for DOS attacks or some new form of hacking.  Also, this would
be a "special case" behavior for login, and I'm sure I speak for all
implementors when I beg you not to create unnecessary special case behavior.
We like a simple state machine for the login process.

I agree, w/Jim, this looks much like a more complicated option B, and the
value escapes me?

Marj 

> -----Original Message-----
> From: Julian Satran [mailto:Julian_Satran@il.ibm.com]
> Sent: Monday, August 27, 2001 9:39 PM
> To: ips@ece.cmu.edu
> Subject: RE: iSCSI: reusing ISID for recovery
> 
> 
> 
> Marjorie, Jim, Mallikarjun, Deva & all
> 
> Let's attemp to close that optimization that is so dear to 
> your hearts.
> If we go for the following scheme (very close to B):
> 
> The initiator knows "that he lost his way" (in the initiator 
> jungle tough)
> and issues a Login + ISID + TSID=0 + X bit on (meaning
> " I think I have an old session - please clean it up for me" 
> and open a new
> one) then the target may do one of the following:
> 
> - before going to the effort of authenticating the new 
> initiator check if a
> session exist (if he has the initiator name) or go to 
> authentication if it
> does not
> - If he has a session then clean it and create a new one
> - If he does not have a session - we have 3 options:
> a)- tell him hid did not have an old session and drop him
> b)- tell him he did not have an old session but nevertheless 
> create a new
> one
> c)- create a new session and do not tell him
> 
> With option a we are close to the old option c but the 
> initiator does not
> have to find the old session he can do now safely a new login
> With b & c  we are back at the old b.
> 
> Which one would you give your kingdom for ( and my peace!).
> 
> Julo
> 
>