On 3/1/2013 2:59 PM, Michael Meffie wrote: > My impression is SetCallBackKey and the related topics could be part of a > Extended Callback document, because of the security considerations of extended > callbacks. If I understand, there is a not a case for securing callback > channels with the current callback RPCs since no information is leaked with > the > current callback RPCs.
Mike, Unprotected callback channels do leak which VolumeIDs and FileIDs are in use by the cache manager and which of those may have been updated. Unprotected callback channels also permit Denial of Service attacks against the cache manager because any IP address can send the cache manager RPCs that invalidate the contents of the cache. What unprotected callback channels cannot do is poison the cache contents until such time as extended callbacks is implemented. Extended callbacks cannot be fully implemented until there are protected callback channels. That does not mean there are not benefits to protecting the callback channels in a world without extended callbacks. Jeffrey Altman
smime.p7s
Description: S/MIME Cryptographic Signature
