Subject: RE: Invalid Pdus received during Login phase

From: "Julian Satran" <[email-masked]>
Date: Fri, 2 Aug 2002 08:42:59 +0300

Pat,

Comments in text.

Thanks,
Julo

[email-masked]
Sent by: [email-masked]
07/30/2002 10:55 PM

        To:     [email-masked], [email-masked]
        cc: 
        Subject:        RE: Invalid Pdus received during Login phase

Praveen,

This appears to be covered in 2.3 Last paragraph on page 33. "Before the 
Full Feature Phase is established, only Login Request and Login Response 
PDUs are allowed. Any other PDU, when received at initiator or target, is 
a protocol error and MUST result in the connection being terminated." 

So, if the target gets PDU that isn't a Login Request PDU during login, it 
closes the TCP connection (it might be more clear to say "TCP connection" 
rather than just "connection" in the text quoted above). It can't send a 
Login Response PDU because it hasn't gotten a Login Request to respond to. 
This response should be valid even if no Login PDUs have been received.

In researching this, I noticed that an earlier discussion on the use of 
protocol error vs negotiation failure seems to have been incompletely 
applied.

4.2.1 last sentence is confusing. It reads: "The selection of a value not 
proposed is considered a negotiation failure and MUST be handled as a 
protocol error." 5.10 and 5.11 cover Negotiation Failures and Protocol 
errors, respectively, so this sentence makes it unclear which applies. It 
should say "The selection of a value not proposed MUST be handled as a 
negotiation failure."
+++ it is a protocol error +++
4.2.2 The same edit applies to the third paragraph of 4.2.2.
+++ protocol error +++
4.3 Page 70 fifth paragraph "is considered a protocol error" should be 
"MUST be handled as a negotiation failure."
+++ protocol error +++
4.4 Page 78 second paragraph from bottom. Should "Reject" be "Reject PDU"? 
"Reject" could be misunderstood to be the value "Reject" but then there 
isn't any way to return "protocol error".
+++ added the word PDU +++
Regards,
Pat

-----Original Message-----
From: Praveen madhavan [mailto:[email-masked]]
Sent: Tuesday, July 30, 2002 4:38 AM
To: [email-masked]
Subject: Invalid Pdus received during Login phase

Hi,
 I would like to know the behavior of Target, when it receives invalid 
Pdu's during login phase. 
   Will target generates login response with Error of status detail 
-"Invalid during login" and terminates the connections. 
Or Reject command with reason code- "Protocol Error/Invalid PDU".

 If Invalid Pdus are received by Target, even before login phase
( I mean just before first login request from initiator), i think target 
can't send login response for it since it was not aware of ISID. In such 
senario how will target react ?

regards
Praveen.M 

------------------------------------------------------------
NEW - FREE Nettaxi 56kbs Dial-up INTERNET ACCESS with NO ADS or Ad Bars!
http://www.nettaxi.com/isp/

---

From: "Julian Satran" <[email-masked]>
Date: Sun, 4 Aug 2002 03:41:43 +0300

OK thanks - Julo

"Robert D. Russell" <[email-masked]>
08/04/2002 12:42 AM

        To:     Julian Satran <[email-masked]>
        cc:     [email-masked]
        Subject:        RE: Invalid Pdus received during Login phase

Julian:

Some trivial typos in working draft 15 (3 August version).

1. Section 2.2.2.1, near the bottom of page 38:
        However CmdSN is as a marker ...
   should be:
        However their CmdSN is a marker ...

2. Section 2.2.6.3.2, near the bottom of page 42:
        encoded hexidecimal digits).
   should be:
        encoded hexadecimal digits).

3. Appendix C, the last example on page 252 has:
        AuthMethod:KRB5,SRP,None
   that colon should be an equal sign:
        AuthMethod=KRB5,SRP,None

Another minor point -- the paragraph in section 9.7.3 on page 156
   that contains the new wording says:

        "On incoming data, the Target Transfer Tag MUST be provided by
        the target if the A bit is set to 1.  The Target Transfer Tag
        and LUN are copied by the initiator in the SNACK of type DataACK
        that it issues as a result of receiving a SCSI Data-in PDU with
        the A bit set to 1 and MUST be set to the reserved value of
        0xffffffff otherwise."

   Of course only the TTT is set to 0xffffffff as a reserved value --
   the LUN is set to 0 when it is reserved.  Since the next paragraph
   seems to cover the necessary details about the 0xffffffff, perhaps
   we could simplify this paragraph to say:

        "On incoming data, the Target Transfer Tag and LUN MUST be
        provided by the target if the A bit is set to 1; otherwise
        they are reserved.  The Target Transfer Tag and LUN are copied
        by the initiator into the SNACK of type DataACK that it issues
        as a result of receiving a SCSI Data-in PDU with the A bit set
        to 1."

A final, less minor point -- I believe the addition of the new last
   paragraph to section 2.2.3 clearly addresses the issue of what
   the target should do when the first PDU it receives on a new TCP
   connection is not a Login request, but still leaves open what it
   should do later during the login phase if it receives a PDU other
   than a Login Request.

   The problem is the wording in the second sentence of the paragraph
   preceeding the new one:

        "Any other PDU, when received at initiator or target, is a
        protocol error and MUST result in the connection being
        terminated."

   This has two sources of misunderstanding --

   1.  It makes it sound as if an initiator can receive a Login Request
       from the target, and the target can receive a Login Response
       from the initiator, both of which are disallowed;
   2.  It makes it sound as if the target can immediately disconnect
       without first sending back a Login-Reject.

   Although the first misunderstanding can easily be resolved by
   refering to other sections of the draft, the second misunderstanding
   occurred at the plugfest.  Of course, my interpretation of its
   resolution may be incorrect, but I believe the target always needs
   to send back a Login-Reject before disconnecting, except when the
   very first PDU on a new TCP connection is not a Login (which is why
   the new paragraph was added to the end of section 2.2.3).

   If my interpretation is correct, could we eliminate the sentence
   just quoted ("Any other PDU, ... being terminated.") and instead
   add the following sentence to the end of the final (new) paragraph
   of this section:

        "Once the Login phase has started, if the target receives any
        PDU except a Login request, it MUST send a Login reject
        (with Status 0x020b) and then disconnect;  if the initiator
        receives any PDU except a Login response, it MUST immediately
        drop the connection."

   If my interpretation is not correct, we need to eliminate the
   Status code 0x020b from the table in section 9.13.5, since
   there appears to be no other use for it.  In this case there
   would also appear to be no reason to single out the first PDU
   on a new connection as being in any way different from subsequent
   PDUs during Login phase.

Thank you for your consideration.

Bob Russell
InterOperability Lab
University of New Hampshire
[email-masked]
603-862-3774