SA Usage Leakage
Ralph Weber
roweber at IEEE.org
Fri Oct 31 18:16:23 PDT 2008
Formatted message: <a href="r0810314_f.htm">HTML-formatted message</a>
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 at us.ibm.com
> http://www-03.ibm.com/servers/storage/
More information about the T10
mailing list