[Lustre-devel] security: rpc message vs bulk data
Eric Mei
Eric.Mei at Sun.COM
Wed Aug 6 09:55:42 PDT 2008
Peter,
Peter Braam wrote:
> Eric - can you add this detail to the presentation about the security
> architecture?
OK.
> On 8/5/08 12:12 PM, "Eric Mei" <Eric.Mei at Sun.COM> wrote:
>
>> Hi,
>>
>> Currently we use different security transformation: on RPC message we
>> use gssapi/kerberos; on bulk data we use separate hash + cipher
>> mechanism. And to some extend the 2 parts can be configured
>> independently. For example, you can use "krb5p" on RPC message while use
>> some light-weight hash/cipher on bulk data for performance or whatever
>> reasons.
>
> We should not use KRB/GSS for bulk data encryption, see below.
>
>> Now we're thinking about using gssapi for both RPC and bulk data. But
>> this way we won't be able to configure them separately. What we're not
>> sure is: is it necessary to be able to set different security level for
>> RPC message and bulk data?
>
> Yes two policies are good to have. Eventually file systems will store data
> encrypted. It would not be a good idea to have encrypt twice - we want to
> ask the client to encrypt the data, send it over the wire and store on disk
> without decrypting.
I see.
Suppose even if we use gss/krb5 for bulk i/o, we can still turn it off
independently. That is to say: suppose we're using gssapi for RPC
message, for bulk data we can choose either use same gssapi to do
protection, or don't do protection at all. Is this approach sounds good
compare to current using completely different policy?
I'm asking this because Darren and Jim pointed out the current bulk i/o
policy is ad-hoc. There's 2 choices: 1) simply using standard mechanism
(e.g. hmac+cipher, CCM/GCM, etc.), still keep it independent of RPC
message policy; 2) suggested by Eric Barton, using the same gssapi for
bulk data as well.
Thanks
--
Eric
More information about the lustre-devel
mailing list