Date: Fri, 07 Nov 2008 19:49:36 -0600 From: Ralph Weber <roweber@IEEE.org> To: Kevin D Butt <kdbutt@us.ibm.com> CC: Black_David@emc.com, t10@t10.org Subject: Re: SA Usage Leakage X-Message-Number: 9282 Formatted message: HTML-formatted message Kevin, Please feel free to write a proposal. Since I disagree with the proposal, I will not write it. Also note that the DS_SAI still cannot be reused until the time that the SA would have expired. If this requirement is not met, a newly created SA could be mistaken for a discarded old one. All the best, .Ralph Kevin D Butt wrote: > > Ralph, > > 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_ <mailto:kdbutt@us.ibm.com>_ > __http://www-03.ibm.com/servers/storage/_ >