Subject: RE: [Ips] Full Feature Phase and Digests

From: "Yao, Xuebin" <[email-masked]>
Date: Fri, 7 Nov 2003 12:55:34 -0800

>> I.e. Only iSCSI op codes 0x00, 0x01, 0x02, 0x04, 0x05, 0x010,
0x1c-0x1e >>(maybe) for the initiator, and 0x20, 0x21, 0x22, 0x24, 0x25,
0x31, 0x32, >>0x3c-0x3e (maybe), 0x3f for the target (anything not
Logout or Login) will >>have the Digests and they must have them if
stated in Login of the >>session?
>> Am I right?

>Not quite. Think of digests as each controled by a boolean, which is
set
>at the end of login processing (if digests were negotiated of course).
If
>the header_digest boolean is set, all PDUs must have a header. If the
>data_digest boolean is set, all PDUs with data segments must have data
>digests.

>The difference between the two views is a matter of how the receive
logic
>is built. If you're in FFP and doing header digests, you evaluate the
>digest before you look at the opcode. You have to do this because until
>you know the header digest is ok, you can't trust the opcode!

Is that always the case? Think about the situation of iSCSI target
receive logic for iSCSI requests with posssible AHS. According to iSCSI
spec, header digest covers both BHS and AHS segments. Since AHS could
come with variable length, without looking at opcode (to determine if
you would expect an AHS) and TotalAHSLength field, the header_digest
would not be possibly validated correctly for the incoming PDUs
containing AHS. 

Agree that "until you know the header digest is OK, you can't trust the
opcode". However, even you look at the opcode/AHSLength to determine if
AHS presents, you don't have to trust them until header_digest (include
AHS segment) is verified OK. 

Otherwise, you may choose to always validate the header_digest for BHS
at first without look at the opcode, if it is not OK, then you have to
double check if AHS presents and if so, need to re-validate digest
again.   

I think it depends on implementation choice. Agree?

Xuebin

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Friday, October 31, 2003 9:20 PM
To: dan yo
Cc: [email-masked]
Subject: Re: [Ips] Full Feature Phase and Digests

On Wed, 29 Oct 2003, dan yo wrote:

> Hi,

> I have a question on whether digest (header and data) can appear
before
> the FFP.

As far as I know, No.

> I found the same question from the archive but couldn't find the
answer, could someone confirm.  Thanks.
> Dan
>
> An earlier email from archive:
>

> I am not sure if this is the place for me to ask this question, so
> forgive me if I am out of line.

> Is there a difference between S5: LOGGED_IN and Full Feature Phase
> (a.k.a. full-feature phase in some parts of the document; it would be
> nice if they were all the same; I am not a regex guru)?

Yes. S6 (IN_LOGOUT) and S7 (LOGOUT_REQUESTED) are also in Full Feature
Phase. I think S8 (CLEANUP_WAIT) also would be FFP, but I'm not sure how
many PDUs get transmitted.

> If so, and I understand the digest section, neither the logout or
login
> PDU's will have digests on them. I believe this holds even after the
> first connection of the session, because later connections are not yet
> in Full Feature Phase (S5).

I think the better way to think about this is to consider when the PDU
was
sent. The connection enters FFP: (initiator) after processing the Login
Response that correctly (*) transitions out of login; (target) after
sending the Login Response that transitions out of login.

(*) The initiator should make sure it is happy with the Login RSP of
course. For instance, if it hadn't set 'T' on the Login Request, it
shouldn't honor 'T' on the RSP.

As logout PDUs are sent after transitioning out of login, they should
have
digests.

> I.e. Only iSCSI op codes 0x00, 0x01, 0x02, 0x04, 0x05, 0x010,
0x1c-0x1e (maybe) for the initiator, and 0x20, 0x21, 0x22, 0x24, 0x25,
0x31, 0x32, 0x3c-0x3e (maybe), 0x3f for the target (anything not Logout
or Login) will have the Digests and they must have them if stated in
Login of the session?
> Am I right?

Not quite. Think of digests as each controled by a boolean, which is set
at the end of login processing (if digests were negotiated of course).
If
the header_digest boolean is set, all PDUs must have a header. If the
data_digest boolean is set, all PDUs with data segments must have data
digests.

The difference between the two views is a matter of how the receive
logic
is built. If you're in FFP and doing header digests, you evaluate the
digest before you look at the opcode. You have to do this because until
you know the header digest is ok, you can't trust the opcode!

Think about the case where transmission corruption changed the opcode
for
a PDU, and made an FFP-phase PDU look like a login PDU. If we looked at
the opcode before the header digest and made a decision based on opcode,
we would look at this as a Login PDU, not pull the digest out of the
command stream, and look at potentially erronious ahs and data segment
length values. And then start processing commands that may not have been
commands. :-)

That's how an initiator and a target need to think about this.

That said, I know that Data Transit make protocol analyzers. For an
analyzer, I think it's fine to know that Login PDUs don't have digests,
and everything else does.

The only place this makes a difference is the corner case where an
initiator sends a Login Request PDU after FFP. If header digests have
been
negotiated, it needs to add a header digest, then the target will reject
the PDU. ;-)  Since this is an error case, if an analyzer doesn't carry
state for the whole connection, it's ok for it to not know FFP and then
just make a choice based on opcode.

Ethereal does this, and it's fine.

Take care,

Bill

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

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

---

From: [email-masked]
Date: Fri, 7 Nov 2003 13:29:45 -0800 (PST)

> receive logic for iSCSI requests with posssible AHS. According to iSCSI

I hadn't touched on AHS. Good to bring up.

> would not be possibly validated correctly for the incoming PDUs

You would have to look at TotalAHSLength in order to find the digest.

> double check if AHS presents and if so, need to re-validate digest

I think it would never be correct to blindly digest-check the BHS w/o
considering TotalAHSLength, as you will never know where the digest is
supposed to be. :-)

I also think your consideration of the opcode in the receive logic is
incorrect. The receive logic should only worry about the framing of
packets, and leave validation to the next software layer.

Yes, a write PDU with an AHS is wrong, but it is not the same kind of
wrong as a PDU with a bad header digest.

Take care,

Bill

---

From: "Randy Jennings" <[email-masked]>
Date: Fri, 7 Nov 2003 14:59:27 -0800

> wrong as a PDU with a bad header digest.
I assume you mean right PDU :-).

I agree that you should not check opcode to see if there _should_ be an
AHS there.  I think what Xuebin's point is that the AHS may be
corrupted, and you would not find the correct spot for the Header
Digest.  I think we are safely assuming that a CRC check on random data
would probably fail.

The interesting part here is a AHS that indicates the digest is beyond
the end of received data (sent TCP stream).  Just something to keep in
mind.  Don't you love corner cases?

Sincerely,
Randy Jennings
Data Transit

---

From: [email-masked]
Date: Fri, 7 Nov 2003 16:10:49 -0800 (PST)

> Digest.  I think we are safely assuming that a CRC check on random data

Yes, we are assuming that a CRC check on random data will fail. Assuming
random data leads to a random CRC, then we have a one in 2^32 chance of
getting a false positive. :-)

> mind.  Don't you love corner cases?

Doesn't matter. TCP is a stream protocol. The AHS and or the digest can
come in subsequent frames. :-)

Take care,

Bill

---

From: "Randy Jennings" <[email-masked]>
Date: Fri, 7 Nov 2003 18:41:31 -0800

> come in subsequent frames. :-)

However, the data bytes perceived as AHS and digest may not ever, if the
length is past what it should be!  I suppose that would be either a
timeout error or caught by a noop.

Sincerely,
Randy Jennings
Data Transit