Re: Logins that are not progressing

On Oct 9, 2006, at 8:48 AM, Paul Hughes wrote:

> I have a few questions related to iSCSI logins based on the  
> following scenarios:
>
> 1) An initiator has begun a login and is now sending multiple Login  
> Request PDU's where the data segment length is zero, T=0, and C=0.
>
> 2) An initiator has begun a login and is now sending multiple Login  
> Request PDU's where the data segment length is non-zero, T=0, and  
> C=0.  For example, the initiator may be sending unique private  
> extension keys in the data segment of each login request PDU.
>
> 3) An initiator has begun a login and is now sending multiple Login  
> Request PDU's with a non-zero data segment length, T=0, and C=1.
>
> Questions:
>
> Is a target allowed to fail a login after some "not making  
> progress" limit is reached in any or all of these scenarios?
> If so, what are some practical "not making progress" limits and  
> what is the proper login response?
> How should a target handle scenario #3 if it has no more resources  
> to handle the ever-growing data segment?
Ok, out of order. #3 is easy. The combined packet (result when all  
the 'C' parts are put together) can't get too big. For large security  
algorithms, the spec notes the receiver should be able to receive  
64k. So just take that as a hard max. If more than that comes in,  
flag it as an initiator error and close the connection. Strictly  
speaking, if you just do CHAP, you don't need to worry about more  
than 8K or so.

For the others, the spec is vague. You can come up with your own  
rules about when a login should fail.

I'd suggest just putting a cap, say 10 or 16 packets, on login nego.  
If login isn't done after that, just kill it off and log the fact you  
did it.

Take care,

Bill

_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips