Subject: [Ips] Full Feature Phase and Digests

From: dan yo <[email-masked]>
Date: Wed, 29 Oct 2003 10:50:16 -0800 (PST)

Hi,
I have a question on whether digest (header and data) can appear before the FFP.
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)?
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.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?

TIA

Sincerely,

Randy Jennings

Data Transit

---------------------------------
Do you Yahoo!?
Exclusive Video Premiere - Britney Spears

---

From: [email-masked]
Date: Fri, 31 Oct 2003 19:19:38 -0800 (PST)

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

As far as I know, No.

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

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