As I understand it, the SA state is
not tied to one initiator or another. Once it is created it uses
the SAI to determine which SA to use. There is no way to determine
if it was another initiator that caused the info to be cleared. This
is a whole new concept where the item in question (the SA) is not tied
to any I_T nexus. Creating a UA for removing SA state information
is not a good idea. In fact it could lead to all applications out
there checking to see if the SA they are using is still available. This
does not make sense to me. In fact, SPC-4 already states that if
the SA Timer expires the state information is discarded and there is no
mention of creating a UA - thankfully. This situation is only slightly
different.
We still believe that:
A) the DS needs to be able to clear
space for a new SA
B) no notification of lost SA should be reported to AC until the AC attempts
to use an SA
C) the expected behaviors of the DS and the AC should be explicitly stated
in SPC-4 and be general (i.e., not tied to each usage defined (e.g., ESP-SCSI))
D) There should be a unique additional sense code for when an attempt to
use an unknown SAI is made (not just 5/2600 pointing to the SA field)
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt@us.ibm.com http://www-03.ibm.com/servers/storage/
From:
Ralph Weber <roweber@IEEE.org>
To:
t10@t10.org
Date:
10/31/2008 06:55 PM
Subject:
Re: SA Usage Leakage
Kevin,
Why is it better to have to define, establish, etc. a UA for
SA CLEARED BY ANOTHER USER than to simply refuse to do that
which cannot be done?
Do not for a minute think that SCSI is going to allow
SAs to be discarded without establishing a UA. That is
simply not done.
Either way there is a messy Denial of Service problem: UAs
out the ying-yang or full frontal request rejection.
Think about it!
All the best,
.Ralph
Kevin D Butt wrote:
I sent out a note on SA Usage Leakage a while back and then lost track
of this item. David Black responded with "I
don't see a problem with this in
principle. The original IKEv2 allows state to be discarded at will."
The original note is:
===========
We have concerns related to SA usage leakage. That is, it is possible
for application clients to create enough SA's in a device server - with
the timeout values long enough - that the device server is out of resources
to create another. While the answer seems obvious - allow the device
server to implicitly abandon an SA for vendor-specific reasons, there is
no explicit mention of this in SPC-4 that we can find. If the DS
is not allowed to implicitly abandon an SA, the opens up the avenue for
Denial of Service attacks - an attacker could use up all the SA resources
with maximum timeout values.
Key points being:
A) the DS needs to be able to clear space for a new SA
B) no notification of lost SA should be reported to AC until the AC attempts
to use an SA
C) the expected behaviors of the DS and the AC should be explicitly stated
in SPC-4 and be general (i.e., not tied to each usage defined (e.g., ESP-SCSI))
D) There should be a unique additional sense code for when an attempt to
use an unknown SAI is made
===========
Also there should be a high-level statement/behavior in the usage model
about attempts to use an unknown SA (not just 5/2600 pointing to the SA
field).
Does anybody disagree with this or agree that this would be a good thing
to do?
Thanks,
Kevin D. Butt
SCSI & Fibre Channel Architect, Tape Firmware
MS 6TYA, 9000 S. Rita Rd., Tucson, AZ 85744
Tel: 520-799-2869 / 520-799-5280
Fax: 520-799-2723 (T/L:321)
Email address: kdbutt@us.ibm.com http://www-03.ibm.com/servers/storage/