RE: Login Proposal

["Ayman Ghanem" <aghanem@cisco.com>]

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: owner-ips@ece.cmu.edu [mailto:owner-ips@ece.cmu.edu]On Behalf Of
> BURBRIDGE,MATTHEW (HP-UnitedKingdom,ex2)
> Sent: Tuesday, August 21, 2001 12:32 PM
> To: 'ips@ece.cmu.edu'; 'Julian Satran'
> Subject: Login Proposal
>
>
> 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: matthewb@bri.hp.com
>
>
>