Re: Logins that are not progressing
"Eddy Quicksall" <[email protected]>
| Newsgroups | gmane.ietf.ips |
|---|---|
| Message-ID | <[email protected]> |
I thought about this once myself. I put a cap of 10. In all my testing I have never seen an initiator go that far.
Eddy
----- Original Message -----
From: William Studenmund
To: Paul Hughes
Cc: IP Storage Mailing List (E-mail)
Sent: Wednesday, October 11, 2006 3:19 PM
Subject: Re: [Ips] 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
_______________________________________________
Ips mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/ips