RE: iSCSI: Login Proposal

["BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <matthew_burbridge@hp.com>]

Stephen,

On the first point:

The proposal does not exclude the Restart Login Command which is still
required for error recovery (7.11.3).  The proposal is applicable to both as
is the current login procedure in 0.7 but if there is something that is
missing from the spec then please bring it up on the IPS.

If the restart bit is set and therefore 7.11.3 is coming into play then the
CID of the restart-connection must be the same as the CID of the initial
connection (2.10.1). In your example CID2=CID1.

I believe if security is required by either or both parties then it needs to
be negotiated on the new connection (otherwise when is it turned on?) and
the same argue applies to operation parameters. Unless I am barking up the
wrong tree, the out come of the two phases need not be the same as the
original connection (as long as the target and initiator agree!).

And the second point:

This is now a separate thread (RE: iSCSI: Option Preference (was Login
Proposal)). I am sitting back and waiting to see what happens.  However, my
thoughts are the IPS need to decide who has power of veto on security and I
think the general opinion is the target. I don't as yet see this effecting
the login proposal but more likely effect some aspect of text negotiation.

I still don't see why we should alienate those initiators/targets who do not
want to negotiate for security.  Security may be achieved by some other
means (e.g. IPsec) and therefore not required at the iSCSI level.

Cheers

Matthew


-----Original Message-----
From: Wheat, Stephen R [mailto:stephen.r.wheat@intel.com]
Sent: Thursday, August 23, 2001 12:49 AM
To: ietf-ips
Subject: RE: iSCSI: Login Proposal


Matthew,

At the risk of violating IETF protocol, I have a new question on the Login
Proposal and a comment on Steve's earlier question.  Please let me know if I
should really have segregated these into two messages.

My question is: Does the Login Proposal propose Restart Login Command no
longer be implemented?  If so, ok fine.  If not, then where can I find the
logic of Restart and having it overlaid with Login versus having a message
type of its own?  E.g., CoalesceCIDs:

	CID 1 is in effect, but Initiator wants to restart it

	I->T  Login CID2
      T->I .... full login process, yadda, yadda
	I->T ....
	T->I  Login CID2 accepted

	I->T CoalesceCIDs CID1 to CID2

	Target verifies CID1 and CID2 are equivalent in all aspects,
		authentication, security, etc.  If so, Target Logs out CID1,
		moves all CID1 state to CID2, and closes TCP connection
associated with CID1.
		The target then replies with success.  Both parties then
mutually rename CID2
		to be CID1.
		If CID1 and CID2 are not equivalent, target logs out CID2
with coalesce failure.

Frankly, I don't know why we really would want Restart semantics, versus
just logging it out.  And as such, I'd prefer removing Restart Login from
the spec.

----------------------

Regarding your answer to Steve's second question...

Given the near consensus on the ability to have <none> listed first, second,
..., last, or not at all, it would appear that we could require an initiator
to include all auth and digest methods it supports AND is willing to have
selected by the target, in preferential order.

In this case, all required flexibility exists, and several protocol
scenarios are removed, thus simplifying the process.  Yes, this is at the
cost of an extra message exchange, but only in what both you and Steve
thought were rare cases.  Is the potential saving of that message exchange
worth the additional scenarios?  I think not.

Stephen

-----Original Message-----
From: BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
[mailto:matthew_burbridge@hp.com]
Sent: Wednesday, August 22, 2001 1:24 AM
To: 'Steve Senum'; ietf-ips
Subject: RE: iSCSI: Login Proposal


Hi Steve,

I forgot to answer your latter two questions in my earlier email!

Comments within:-

Cheers

Matthew

-----Original Message-----
From: Steve Senum [mailto:ssenum@cisco.com]
Sent: Tuesday, August 21, 2001 9:14 PM
To: ietf-ips
Subject: Re: iSCSI: Login Proposal


Matthew/Marjorie/Bob:

Some questions on your login proposal:

1. Why the following restriction?

    SecurityContextComplete=yes MUST NOT be present
    in the login command.

I don't see the benefit in not allowing something like:

I: AuthMethod:none
   HeaderDigest:crc-32c,none
   DataDigest:crc-32c,none
   SecurityContextComplete=yes
T: AuthMethod:none
   HeaderDigest:crc-32c
   DataDigest:crc-32c
   SecurityContextComlete=yes

2. In the following:

    If the login command does not contain security parameters
    the target MUST perform one of the two actions below:

    a) If the target requires security negotiation
       to be performed, then it MUST enter the security
       phase and MUST send a text response containing
       one or more security parameters and F=0.

    b)

Is this really needed?  Why not simply require the
initiator to offer security parameters if it supports them?
I would hope authentication would become the typical case
for login.

MATTHEW: So I was maintaining flexibility here.  If an initiator prefers not
to negotiate security then why force it? Also, the login is faster if
neither side want to negotiate security.  I think the majority of people
would go for flexibility and provided that the procedure caters for all four
scenarios of either side wanting/not wanting security then the flexibility
should be present.  In other words, as long as the flexibility does not
cause interoperability problems and allows everyone to do what they want to
do then the flexibility should be there. I agree that the typical case would
be to include authentication but some people will always want to skip it.

3. Is there only one Login Reponse then (just asking)?

MATTHEW: yes.  In deriving the proposal we came to the conclusion that the
partial login response is unnecessary so we removed it.  Also, some
implementers have said that this makes the implementation easier as they
will always return a text response unless login is completed (successfully
or otherwise).

Regards,
Steve Senum