Subject: Re: iSCSI - Change - Login/Text commands with the binary stage code

From: "Julian Satran" <[email-masked]>
Date: Sat, 25 Aug 2001 09:26:04 +0300

Steve,

my comments in text - Julo

Steve Senum <[email-masked]>@ece.cmu.edu on 25-08-2001 01:54:47

Please respond to Steve Senum <[email-masked]>

Sent by:  [email-masked]

To:   ietf-ips <[email-masked]>
cc:
Subject:  Re: iSCSI - Change - Login/Text commands with the binary stage
      code

Hi Julian,

A have two questions on your proposal with respect to the
new CNxSG field.

1. In the section:

>    Stage transition is performed through a command exchange
>    (request/response) carrying the F bit and the same current stage code.
>    During this exchange, the next stage selected is the lower of the two
>    next stage codes.  The initiator can request a transition whenever it
is
>    ready but a target can respond with a transition only after it is
>    offered one by the initiator.

I assume from this that the target must always return the
same "current stage" as the initiator, so there is no
way for the stages to go backwards (which is fine with me).

+++ that is correct. Stages can't go backwards +++

2. In the section:

>    If the initiator is willing no negotiate security but it is unwilling
to
>    make the initial parameter offer and may accept a connection without
>    security it issues the Login with the F bit set to 1, the CNxSG set to
>    SecurityNegotiation in the current stage and
LoginOperationalNegotiation
>    in the next stage. If the target is also ready to forego security the
>    Login response is empty and has F bit is set to 1 and the CNxSG set to
>    SecurityNegotiation in the current stage and
LoginOperationalNegotiation
>    in the next stage.

So, if the initiator opens with:

I-> Login (CNxSG=0,1 F=1)

And the target responds with:

T-> Login-PR (CNxSG=0,1 F=0) AuthMethod=CHAP

And the initiator responds with:

I-> Text (CNxSG=0,1 F=0) AuthMethod=CHAP

The target should respond with a blank text message?

T-> Text (CNxSG=0,1 F=0)

Since all of the AuthMethods in Appendix A specify
that the initiator MUST start the authentication sequence
(which is fine with me).
++++ that is a correct sequence but the initiator could as well start the
parameters on the same PDU it is acking the use of CHAP like:

I-> Text (CNxSG=0,1 F=0) AuthMethod=CHAP A=<A1,A2...>

True the sequences are not symmetric as we decided early on that the target
has to reject and say why while the initiator will drop connections.

+++++
Regards,
Steve Senum

---

From: Steve Senum <[email-masked]>
Date: Wed, 29 Aug 2001 15:59:36 -0500

Julian,

A couple of ideas from Matthew Burbridge & Co.'s
login proposal that has generated some interest here:

1. Removal of partial login response.  Is it still needed?

2. Requiring Initiator and (if not a discovery session)
   Target names on login command, so they are always
   available if needed by the initial phase.

Comments?

Regards,
Steve Senum

---

From: Steve Senum <[email-masked]>
Date: Wed, 29 Aug 2001 16:12:28 -0500

Julian,

In the following section:

   If the initiator decides to forego the SecurityNegotiation stage it
   issues the Login with the CNxSG set to LoginOperationalNegotiation in
   the current stage and the target may replay with a Login Response
   indicating that it is unwilling to accept the connection without
   SecurityNegotiation and terminate the connection.

This seems contrary to the requirement to implement
authentication (at least AuthMethod=SRP).  I realize
this could also be a configuration issue, but I wonder
if the spec should at least strongly recommend starting
with phase SecurityNegotiation, or better yet, make it
a SHOULD?

Regards,
Steve Senum