Subject: Login Proposal

From: "BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)" <[email-masked]>
Date: Tue, 21 Aug 2001 18:32:11 +0100

The recent plugfest highlighted areas of the login procedure that could be
improved.
With this in mind, Bob Russell, Marjorie Krueger, and myself have been
working on
a proposal for the Login procedure.

Our goals were to keep it inline as much as possible with 0.7 of the
specification and
to ensure connectivity can be maintained amongst target and initiators.  I
believe we
have meet all the goals we set out to do.

I have also attached a Login Reference Model (in the form of c code) which
backs up
our proposal.  Please note that the reference model is only a reference
model and should
not be considered as, or be part of the iSCSI specification.

Cheers

Matthew Burbridge
Marjorie Krueger
Bob Russell

++++++++++++++++++++++++

The Login Proposal:

Definitions:
FBit means "I have nothing (more) to negotiate"
Request: The first occurrence of a Text Parameter from the initiator or the
target. A request 
         MUST be answered with a reply.
Reply: A Text Parameter that is a response to a Request.
Negotiation: A request followed by a response.

1.1 Actions at the Initiator

The initiator starts the login phase by sending a Login Command PDU.

The IIN MUST be present in the login command.  The SessionType MUST be
present if the
session type is Discovery, Boot or CopyManager.  It MAY be present if
SessionType=Normal.
The ITN MUST be present unless SessionType=Discovery when it is optional.
The initiator
MUST NOT send operational text parameters in the login command.  The table
below defines
the parameter present in the login command.

        SessionType        SessionType          IIN               ITN
                           Present in        Present in        Present in
                             Login?            Login?            Login?

          Normal            Optional            Yes               Yes
           Boot               Yes               Yes               Yes
        CopyManager           Yes               Yes               Yes
         Discovery            Yes               Yes             Optional

SecurityContextComplete=yes MUST NOT be present in the login command
Operational Parameters MUST NOT be present in the login command

At anytime the initiator MAY terminate the login killing the TCP connection.

If the initiator requires security negotiation it MUST send one or more
security
parameters: (AuthMethod, HeaderDigest, DataDigest) in the login command.

             Fbit     Security
                     Parameters     Description
                      Present

              0          No         Initiator has no security parameters
                                    to negotiate but has operational
parameters
                                    to negotiate.
 
              0          Yes        The initiator wants to negotiate
security.

              1          No         The initiator has no security parameters
to
                                    negotiate and no operational parameters
to
                                    negotiate.

              1         Yes         ILLEGAL.  Target must reject login
                                    (Login Status = 0200)

1.2 Actions at the Target

On receipt of the Login Command the target MUST respond according to the
rules below:

If the InitiatorName is not present the target MUST reject the login
by sending a Login Response with FBit=1 and StatusCode=0200.  Similary, if
the
SessionType is not Discovery and the TargetName is not present the target
MUST
reject the login by sending a Login Response with FBit=1 and
StatusCode=0200. It
both cases the target should kill the TCP connection after the login
response has
successfully been sent.

At anytime the target MAY terminate the login by sending a login response
with
the FBit set to 1 and a non-zero StatusCode. The target should kill the TCP
connection after the login response has successfully been sent.

If the login command contains security parameters, the target MUST enter the
security
phase of the login.  It MUST send response to those security parameters and
MAY start
negotiating security parameters if the parameters that it wants to negotiate
are not
in the Login command.  The target responses with a Text Response (F=0).

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) If the target does not require security negotiation (and therefore
neither
         does the initiator) it MUST perform one of the actions defined by
the table
         below.

              Initiator    Target has     Action
                FBit       params to
                           negotiate

                 0            No         Send Text Response with F=1
(Initiator
                                         only wants to negotiate operational
                                         parameters).

                 0            Yes        Send Text Response with operation
params
                                         If all parameters can be sent in
                                         a single response then F=1 else F=0
                                         (Both target and initiator want to
                                         negotiate operational parameters).

                 1            No         Send Login Response with F=1.
(Neither target
                                         nor initiator want to negotiate
operational
                                         parameters).

                 1            Yes        Send Text Response. If all
parameters can be
                                         sent in a single response then F=1
else
                                         F=0 (Target only wants to negotiate
                                         operational parameters).

1.3 General Rules

If an initiator or target has text parameters (security or operational) to
negotiate
then it MUST send them at the earliest opportunity and it MUST NOT send an
empty text
command.

An initiator or target MUST respond to the a text parameter request with a
text parameter
response in the next text PDU to be sent.

Once an initiator or target has completed initiating negotiations (security
or operational)
it MUST not initiate any more of the same type (security or operational).
In other
words it can not go backwards.

Operational Parameters MUST NOT be negotiated during the security phase.
Security Parameters MUST NOT be negotiated during the operartional phase.

When a party has no more text parameters to negotiate then the FBit MUST
be set in the PDU containing the last text parameter request and all
subsequent
PDUs.  For example: if an initiator only wants to negotiate "InitialR2T=yes"
and no others, then it MUST set the FBit to 1 in the commands containing
"InitialR2T=yes".

Once the FBit has been set to 1, it MUST not be set back to 0.  Also, if
the FBit is 1 then the party MUST not instigate anymore text parameter
negotiations.  It can only respond to requests from the other party.

If FMarker=yes then SFMarkInt and RFMarkInt MUST be present in the same
Text PDU as FMarker=yes.  If FMarker=no then SHOULD NOT be present.  If they
are then the remote party MUST reply to them and echo the values sent in the
initial PDU.

1.4 Completion of Security Phase
[Authors note: This section has been extracted from v0.7 but I have made
some
clarifications to the version 0.7 spec. - Changes in CAPITALS]

          -Every party in the security negotiation MUST [Added MUST]
           indicate that it has completed building its security context
           (has all the required information) by sending the key=value pair:

              SecurityContextComplete=yes 
            
           The other party either offers some more SECURITY parameters or
answers 
           with the same: 
            
              SecurityContextComplete=yes 

           The party that is ready MUST [Added MUST] keep sending the 
           SecurityContextComplete=yes pair (in addition to new security 
           Parameter REPLYS if required) until the handshake is complete. 
	   Once the party has set SecurityContextComplete=yes it MUST
           not instigate anymore negotiations but it MUST respond to any
           requests from the other pary.
            
           If the initiator has been the last to complete the SECUIRTY PHASE
it 
           MUST NOT start sending operational parameters within the same 
           text command; a text response including only 
           SecurityContextComplete=yes concludes the security sub-phase. 
            
           If the target has been the last to complete the SECURITY PHASE,
the 
           initiator can start the operational parameter negotiation with 
           the next text command; the security negotiation sub-phase ends 
           with the target text response. 
            
           The SecurityContextComplete handshake MUST be performed if any 
           of negotiating parties has offered a security/integrity item 
           (even if it is not selected). 
            
           All PDUs sent after the security negotiation sub phase MUST be 
           built using the agreed security.  

This proposal removes from 0.7 of the spec:
Partial Login response: It no longer coveys any information.
OpParamReset: No longer required as operational parameters can not be
negotiated
during security phase.

Keep:
SecurityContextComplete=yes.  This is how 0.7 works.  If people disagree
then
we can vote and change it.

Matthew Burbridge
Senior Development Engineer
NIS-Bristol
Hewlett Packard
Telnet: 312 7010
E-mail: [email-masked]

---

From: Steve Senum <[email-masked]>
Date: Tue, 21 Aug 2001 15:13:48 -0500

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.

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

Regards,
Steve Senum

---

From: Tow Wang <[email-masked]>
Date: Tue, 21 Aug 2001 19:06:44 -0700

Julian (and all):

Hello. This is regarding draft 07; could we require that target records NOT span across
PDU's if a text response for SendTargets is very long? Upon reading appendix E, it seems
that a response (of 4096 bytes in length) could end with:

[Begin data segment]
...
TargetName=I.got.chopped.4096
TargetAddress=10.1.1.45
[End data segment]

In the above case, one could not determine whether the address is IP V4 or V6. Even if it
had had enough space to put in the whole address, port and group tag, one cannot parse and
process the record until inspecting the data segment of the next text response PDU, and
this would involve cumulative buffering, back-parsing, etc. I think the above complexity
could be avoided, as I can't imagine any single record exceeding 4096 bytes in length.

Tow Wang

---

From: "Ayman Ghanem" <[email-masked]>
Date: Wed, 22 Aug 2001 08:56:42 -0500

I would vote in favor of requiring IIN and ITN to be sent in the login cmd.
If either is missing, the appropriate login response status code is 0x0207
(F=1). I would also vote in favor of eliminating the partial login response.
If we agree that a connection is not in full feature phase until it has
completed the login sequence, then the fields returned in the partial login
response (TSID, ExpCmdSN, MaxCmdSN) are of no use, and a text response can
replace a partial login response.

One comment though. If the initiator has no security parameters to negotiate
(implied by absence of all 4 security keys), then the initiator should be
allowed to include the operational parameters in the login cmd and set F=1.
This would conclude the login in just one exchange (unless the target
restarts the negotiation).

-Ayman

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
> Sent: Tuesday, August 21, 2001 12:32 PM
> To: [email-masked]'; 'Julian Satran'
> Subject: Login Proposal
>
>