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