Re: [EXTERNAL] Re: Review of draft-ietf-nfsv4-rpc-tls04

Chuck Lever <[email protected]> Fri, 6 Dec 2019 14:46:17 -0500
Newsgroups gmane.ietf.nfsv4
Message-ID <[email protected]>

> On Dec 6, 2019, at 2:24 PM, Tom Talpey <[email protected]> wrote:
> 
>> -----Original Message-----
>> From: Chuck Lever <[email protected]>
>> Sent: Friday, December 6, 2019 2:12 PM
>> To: David Noveck <[email protected]>; Black, David
>> <[email protected]>
>> Cc: Tom Talpey <[email protected]>; NFSv4 <[email protected]>
>> Subject: Re: [nfsv4] [EXTERNAL] Re: Review of draft-ietf-nfsv4-rpc-tls04
>> 
>> 
>> 
>>> On Dec 6, 2019, at 11:53 AM, David Noveck <[email protected]>
>> wrote:
>>> 
>>> On Fri, Dec 6, 2019 at 10:28 AM Tom Talpey <[email protected]>
>> wrote:
>>>> -----Original Message-----
>>>> From: nfsv4 <[email protected]> On Behalf Of Chuck Lever
>>>> Sent: Friday, December 6, 2019 10:11 AM
>>>> To: David Noveck <[email protected]>
>>>> Cc: NFSv4 <[email protected]>
>>>> Subject: [EXTERNAL] Re: [nfsv4] Review of draft-ietf-nfsv4-rpc-tls04
>> 
>>>> Essentially, we want to require that the host separates
>>>> the encryption of each tenant's traffic.
>>> 
>>> I think the move from "user identiy domain" to "tenant" is helpful here even
>>> though you would have to explain what multipe tenants, which, as Tom
>>> points out, can alsooccur without virtalization per se, bein involved.
>> 
>> 
>> Fair 'nuf. To me "tenant" and "user identity domain" mean the same thing
>> in this context. In Linux, a tenant container is represented by a set of
>> namespaces, one of which controls the user identity mapping. So "user
>> identity domain" seems natural to me, but maybe not to others.
>> 
>> RFC 4949 does not have a convenient definition of "tenant."
>> 
>> RFC 7644 Section 6 comes close.
>> 
>> David Black, perhaps you might have thoughts based on your work on
>> network virtualization overlays ( RFCs 736[45] )?
> 
> I'm arguing the opposite - that there's no need to bring in "tenant" or
> "virtualization" or adding references to nvo, etc. Unless you have a very
> specific vulnerability in mind that this needs to cover.
> 
> In other words, keep it simple and at the highest-level abstraction possible.

I'm flexible, and philosophically agree that an abstract requirement
would be best. I just don't yet see how to make that happen. "Tenancy"
seems to me like an inseparable part of the discussion.

If you have an example, that would help.


--
Chuck Lever



_______________________________________________
nfsv4 mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/nfsv4