Subject: [Ips] Logins that are not progressing

From: "Paul Hughes" <[email-masked]>
Date: Mon, 9 Oct 2006 09:48:30 -0600

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?

Thanks,
Paul

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

---

From: William Studenmund <[email-masked]>
Date: Wed, 11 Oct 2006 12:19:32 -0700

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

> 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?
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

---

From: "Eddy Quicksall" <[email-masked]>
Date: Fri, 13 Oct 2006 17:35:30 -0400

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

    Questions: 

  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

------------------------------------------------------------------------------