Subject: RE: iSCSI: Login negotiation space

From: "Julian Satran" <[email-masked]>
Date: Tue, 2 Jul 2002 22:35:51 +0300

Pat,

4k is absurd. We have the security guys asking for 64k certificates!
And the PDUlength default is 8k!
Besides you can control the total memory consumed by throttling login as 
soon as you have unprocessed keys exceeding the mount of memory you want 
to keep aside (you control the login progress by delaying 
requests/responses).

Julo

[email-masked]
07/02/2002 10:02 PM
Please respond to pat_thaler

        To:     Julian Satran/Haifa/IBM@IBMIL, [email-masked]
        cc:     [email-masked]
        Subject:        RE: iSCSI: Login negotiation space

Julian,
 
A factor of 10 is way overkill. It isn't just 16 k bytes of extra memory. 
It is n * 16k where n is the number of simultaneous logins the 
implementation supports - it adds up. The system vendors we work with want 
to use the memory to do useful work and demand that driver sizes be kept 
small -- they want the memory available to do "real" work. 
 
If 2k doesn't leave enough headroom, then we could live with somewhat more 
like 4k. 
 
If future features added to iSCSI require more space, the drivers that 
support that can allocate more memory. It is an internal parameter that 
can be changed when the need arises. There is no future interoperability 
need to make the buffer oversized in current implementations.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Tuesday, July 02, 2002 12:10 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: iSCSI: Login negotiation space

Pat, 

A factor of 10 over what is needed today is what I would call a 
conservative design. 
Limiting the support to 2k would be extremely unwise. 
And 16 is a tiny amount of memory - of no concern to software 
implementation and to most hardware implementations. 

Julo 

[email-masked] 
07/02/2002 01:56 AM 
Please respond to pat_thaler 
        
        To:        Julian Satran/Haifa/IBM@IBMIL 
        cc:        [email-masked] 
        Subject:        RE: iSCSI: Login negotiation space 

Julian,

4.1 contains a requirement that initiators and targets support receiving 
at least 16384 bytes of key=value data (when not supporting very long 
authentication items). This is overkill and is making drivers larger than 
they need to be. 

My calculations are that Security negotiation using the CHAP method 
(including the Any-stage keys) takes less than 1600 bytes. Operational 
negotiation requires 1276 bytes (also including the Any-stage keys). All 
the operational plus security keys are 1911 bytes.

Therefore an implementation could hold all the necessary keys in 2 Kbytes. 
And, the implementation doesn't need to keep the security keys after the 
security negotiation is done so it could clear some of that out to make 
room for future keys or vendor specific keys. 16 K bytes is about 10 times 
the necessary storage in that case.

The number of negotiation bytes that a device is required to support 
should be reduced substantially - preferably to 2048 bytes.

Regards,
Pat

The numbers:

 43                                  AuthMethod
          CHAP keys 
264                                  Name (no defined size limit - using 
255)
 11                                  Algorithm
 11                                  Identifier
264                                  Challenge
 42                                  Response (for MD5)
_____
635 Chap negotiation length
892 Any-stage keys
----
1527

Operational negotiation keys
 24                                  HeaderDigest
 24        DataDigest
 49        MaxConnections
270                                  TargetName* or InitiatorName*
271                                  TargetAlias* or InitiatorAlias*
273        TargetAddress*
 55                                  TargetPortalGroupTag*
 15                                  InitialR2T
 19                                  BidiInitialR2T
 18                                  ImmediateData
 34                                  MaxRecvDataSegmentLength
 24                                  MaxBurstLength
 26                                  FirstBurstLength
 24                                  DefaultTime2Wait
 26                                  DefaultTime2Retain
 25                                  MaxOutstandingR2T
 18                                  DataPDUInOrder
 24                                  DataSequenceInOrder
 24                                  ErrorRecoveryLevel
 23                                  SessionType*
------
892 Any-stage keys
384 Not Any-stage
------
1276 Operational keys

---

From: Michael Morrison <[email-masked]>
Date: 02 Jul 2002 15:59:07 -0700

Julian,

Your comment about controlling login progress by delaying
requests/responses begs the question:  How long is too long?

I actually have a question about delaying login during Session
Reinstatement.  Say a target receives a login indicating Session
Reinstatement.  The target must internally abort all tasks on the
session, but this may take a very long time and the implementer may not
want to complete the reinstatement login until all the tasks are
aborted;  again,  how long is too long?

Perhaps a blurb in a new section (6.3.3?) on Timeouts on Login, or
Timeouts on Session Reinstatement?  

Mike
 
On Tue, 2002-07-02 at 12:35, Julian Satran wrote:

    Pat,
    
    4k is absurd. We have the security guys asking for 64k certificates!
    And the PDUlength default is 8k!
    Besides you can control the total memory consumed by throttling
    login as soon as you have unprocessed keys exceeding the mount of
    memory you want to keep aside (you control the login progress by
    delaying requests/responses).

    Julo

    
    [email-masked]
    
    07/02/2002 10:02 PM
    Please respond to
    pat_thaler

            To:      
    Julian
    Satran/Haifa/IBM@IBMIL, [email-masked]
            cc:      
    [email-masked]
            Subject:      
    RE: iSCSI: Login
    negotiation space

    Julian,
     
    A factor of 10 is way overkill. It isn't just 16 k bytes of extra
    memory. It is n * 16k where n is the number of simultaneous logins
    the implementation supports - it adds up. The system vendors we work
    with want to use the memory to do useful work and demand that driver
    sizes be kept small -- they want the memory available to do "real"
    work. 
     
    If 2k doesn't leave enough headroom, then we could live with
    somewhat more like 4k. 
     
    If future features added to iSCSI require more space, the drivers
    that support that can allocate more memory. It is an internal
    parameter that can be changed when the need arises. There is no
    future interoperability need to make the buffer oversized in current
    implementations.
     
    Regards,
    Pat
     
    -----Original Message-----
    From: Julian Satran [mailto:[email-masked]]
    Sent: Tuesday, July 02, 2002 12:10 AM
    To: [email-masked]
    Cc: [email-masked]
    Subject: RE: iSCSI: Login negotiation space

    Pat,

    Julo

    
    [email-masked]
    
    07/02/2002 01:56 AM
    Please respond to
    pat_thaler 
            
           To:      
    Julian
    Satran/Haifa/IBM@IBMIL
           cc:      
    [email-masked]
           Subject:      
    RE: iSCSI: Login
    negotiation space

    
    Julian,
    
    4.1 contains a requirement that initiators and targets support
    receiving at least 16384 bytes of key=value data (when not
    supporting very long authentication items). This is overkill and is
    making drivers larger than they need to be. 
    
    My calculations are that Security negotiation using the CHAP method
    (including the Any-stage keys) takes less than 1600 bytes.
    Operational negotiation requires 1276 bytes (also including the
    Any-stage keys). All the operational plus security keys are 1911
    bytes.
    
    Therefore an implementation could hold all the necessary keys in 2
    Kbytes. And, the implementation doesn't need to keep the security
    keys after the security negotiation is done so it could clear some
    of that out to make room for future keys or vendor specific keys. 16
    K bytes is about 10 times the necessary storage in that case.

    Regards,
    Pat

    The numbers:
    
    43                                  AuthMethod
             CHAP keys 
    264                                  Name (no defined size limit -
    using 255)
    11                                  Algorithm
    11                                  Identifier
    264                                  Challenge
    42                                  Response (for MD5)
    _____
    635 Chap negotiation length
    892 Any-stage keys
    ----
    1527

    

    

Michael Morrison
ISTOR Networks
7585 Irvine Center Dr. Ste 250
Irvine Ca. 92618
PGP Key: 74C30155