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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.