Subject: [Gen-art] Gen-art LC review of draft-ietf-nfsv4-minorversion2-39

From: Elwyn Davies <[email-masked]>
Date: Sun, 13 Dec 2015 19:22:38 +0000

I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Document: draft-ietf-nfsv4-minorversion2-39.txt
Reviewer: Elwyn Davies
Review Date: 2015-12-13
IETF LC End Date: 2015-12-09
IESG Telechat date: (if known) -

Summary: Almost ready.  There are a fair number of minor nits and 
editorial suggestions.  The couple of 'minor issues' are predominantly 
questions that came into my mind that might be interesting to a 
reader/implementer but are probably unlikely to affect the performance 
of the protocol.  However, the comments on s11.2, s12.1, s13 and s15.2.3 
appear to be actual omissions or errors.

Major issues:
None.

Minor issues:
s4:  There is no discussion in s4 of the Named Attributes associated 
with a file and the restriction of server-to-server copy to 'regular 
files' seems to indicate that Named Attributes cannot be copied by this 
mechanism.  Is there anything to be said about getting the Named 
Attributes across?

s4/s9:  Does server-to-server copy interact (badly, or otherwise) with 
Labeled NFS?  Nothing is said, but I wonder whether there are issues 
around atomicity and MAC between the different servers for inter-server 
copy.

s4.10.1.1.1: Size and reuse for random number used as a shared secret 
for inter-server copy.
No advice is given on the desirable size/length of the random number or 
the risks or otherwise of reusing the same context for multiple file 
copies.  This maybe a non-issue - I defer to those with more security 
clue than me.

Nits/editorial comments:
General: bytes or octets?

Abstract: Probably ought to expand i/O.

s1/s1.1: I think you could safely delete the s1.1 header leaving the 
text as the body of s1 - this is generally considered better practice 
than leaving s1 itself empty.

s1.2, 3rd bullet: s/protocols.  I.e.,/protocols, that is/; s/apply/apply 
only/

s1.4:  The overview doesn't cover the two LAYOUT related operations and 
there is is no section describing what their usage might be in with 
sections 4-10.

s1.4: Similarly, there is noting about the CLONE operation.

s1.4.1, para 1: s/remotely accessed/remotely accessed file/; 
s/location/locations/

s1.4.1: (very nitty!) Suggest making the descriptions of the two cases 
(intra- and inter-server) into bulleted paragraphs to make it clearer 
that they are separate features.

s1.4.2: (as with the Abstract) expand I/O on first occurrence.

s1.4.2: It would be worth putting in the reference for posix_fadvise here.

s1.4.3: If you write the data in the hole, it isn't really a hole ;-) ....
OLD:
Such holes are typically transferred as 0s during I/O.
NEW:
Such holes are typically transferred as 0s when read from the file.
END

s1.5: Suggest s/I.e., READ becomes either/For instance, READ would have 
to be replaced or supplemented by, say, either/

s2, last bullet: Need to expand pNFS on first use (and maybe remind 
readers that it is a feature of NFS4.1 - Section 12 of RFC 5661)

s2, last bullet: s/metadata sever/metadata server/ - again a pointer to 
(say) Sections 1.7.2.2 and 12.2.2 of RFC 5661 would clarify what a 
metadata server is.

s4.2.1:  The first para reads:
OLD:
    COPY_NOTIFY:  Used by the client to notify the source server of a
       future file copy from a given destination server for the given
       user.  (Section 15.3)

I completely misread this on first pass, but I understand that it is 
correct.  Having checked with s15.3 and thought a bit more about it, it 
is the 'copy from a given destination' that threw me - I guess it means 
'the copy will be made from' rather than 'the file being copied from the 
destination'... Doh!
> A client sends this
>     operation in a COMPOUND request to the source server to authorize a
>     destination server identified by cna_destination_server to read the
>     file specified by CURRENT_FH on behalf of the given user.

I suggest the following might be avoid this brain fade:
NEW:
    COPY_NOTIFY:  Used by the client to request the source server to 
authorize a
       future file copy that will be made by a given destination server 
on behalf of the given
       user.  (Section 15.3)
END

s4.2.2, para 5:  s/support all these operations/support these 
operations/ ('all' is confusing given that only two are then explicitly 
mentioned).

s4.3, para 1:  s/Inter-server copy is driven/The specification of 
inter-server copy is driven/

s4.4.1, last para: s/The source MUST equate/The source MUST interpret/

s4.6/Figures 4 and 5: Need a 'key' to explain os1 and os2.

s4.7.2:  Adding a reference to Section 15.3(.3) would help.

s4.7.3, para 2: idnits identifies RFC 2616 as obsoleted by RFC 7230, 
etc.  A more recent ref is desirable.

s4.8, para after code fragment: LDAP and NIS  need to be expanded (DNS 
and URL are well-known).

s4.9, para 3: Is it possible to add a little explanation as to *why* 
seqid = 0 is ambiguous?  My limited knowledge doesn't grok this.

s4.10: Is it possible to provide an abstract definition of 'structured 
privilege'?  The rpcsec-gssv3 draft appears to punt on this, pointing to 
the 'example' in the NFSv4.2 draft.  I think I get the idea but a 
succinct definition would help I believe.   I guess the definition ought 
to be in the rpcsec-gss document and referenced from this doc.

s4.10.1.1.1, 2nd bullet: Need to expand QOP.

s4.10.1.2, para 2: s/uiniquely/uniquely/

s5, title: s?IO?I/O?

s6.1: This heading could be deleted turning the text in 6.1 into Section 
6 which is then not empty.

s6.1: The term 'inode' is used four times in this section.  Whilst this 
is well understood, it is strictly associated with *nix file systems. It 
would be desirable to find an alternative term or, if you can't think of 
suitable short generic term (I spent a little time thinking about it and 
couldn't think of one immediately), some weasel words added to the first 
occurrence saying that it is intended to cover equivalent structures in 
other sorts of filing system.

s6.1, para 2: s/can thought as holes/can thought of as holes/

s6.1, para 4:  s/couple/few/  ('couple hundred' is a USA specific 
colloquialism - UK would use 'couple of')

s6.1, last para: s/punching.  I.e., an application/punching, where an 
application/

s7, para 1: s/One example is the posix_fallocate/One example is the 
posix_fallocate operation/

s7
OLD:
    space_freed  This attribute specifies the space freed when a file is
       deleted, taking block sharing into consideration.
NEW:
    space_freed  This attribute reports the space that would be freed 
when a file is
       deleted, taking block sharing into consideration.

s8, bullet #2:
I found the 2nd sentence hard to parse.  Suggested alternative below.
OLD:
    2.  Fields to describe the state of the ADB and a means to detect
        block corruption.  For both pieces of data, a useful property is
        that allowed values be unique in that if passed across the
        network, corruption due to translation between big and little
        endian architectures are detectable.  For example, 0xF0DEDEF0 has
        the same bit pattern in both architectures.
NEW:
    2.  Fields to describe the state of the ADB and a means to detect
        block corruption.  For both pieces of data, a useful property 
would be
        that the allowed values are specially selected so that if passed 
across the
        network, corruption due to translation between big and little
        endian architectures is detectable.  For example, 0xF0DEDEF0 has
        the same (32 wide) bit pattern in both architectures, making it 
inappropriate.
END
PS: The example is relevant to 32 bit memory architectures... It has 
never occurred to me to ask if there are 64 bit big and little endian 
architectures!  Well the IA-64 is bi-endian...

s8.3:  The pictures of the memory patterns don't match the specification 
in that the guard pattern appears to be at octet offset 4 in each ADB - 
You can't tell where the checksum is from the pictures, but as specified 
there would be a 4 octet gap between the guard pattern and the checksum 
- I presume this is intentional. Would it be guaranteed to be zero?

s9.1:  Again it would be best to delete the title of s9.1 and leave the 
text as s9.

s9.1, para 2: Expand ACL please.

s9.1/s9.6.1.3: I am dubious about referring back to the requirements doc 
[RFC7204] for definitions (rather than indicating what requirements were 
met/not met) .  For the ref in s9.1, I think that the MAC definition in 
RFC 4949 would suffice. [I noted when reviewing the rpcsec-gssv3 draft a 
couple of days ago that it makes *normative* reference to RFC 7204 - 
this is even more undesirable - my feeling is that it should be possible 
to find out what implementers need to know from the NFSv4.2 standard, 
other standards or the security glossary as there is no certainty that 
what is said in the requirements was actually put into the standard, 
which could cause confusion for future implementers.]  Is it possible to 
get everything an rpcsec-gssv3 implementer needs to know into this 
document?  My impression is that it is almost all there already.

s9.2, MLS definition: RFC 2401 has been obsoleted by RFC 4301... can 
this be referenced instead?

s9.4: Expand DS and MDS on first occurrence (these should probably go 
back in s3 where metadata servers and data servers are referred to but 
without the abbreviations).

s11.2, Table 2: The operation IO_ADVISE is missing from the table. 
[CAVEAT: I don't claim to have checked the possible error codes!] 
Aesthetically, this table would be better with horizontal separators 
between the operation items.

s12.1, Table 4:  The data types of clone_blksize (length4 vs uint32_t) 
and space_freed (length4 vs uint64_t) do not match between this draft 
and the XDR draft.

s12.2.3, NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR:
Monotonic is not really a good name for this I think.  This is because 
the technical definition is either non-increasing or non-decreasing so 
that it would theoretically cover situations where the change attribute 
doesn't actually change! IMO a better name would be 
NFS4_CHANGE_TYPE_STRICTLY_INCR.  This would imply that the value 
actually increases whenever the info changes.

s12.2.3:  With reference to the previous comment...
OLD:
    If either NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR,
    NFS4_CHANGE_TYPE_IS_VERSION_COUNTER, or
    NFS4_CHANGE_TYPE_IS_TIME_METADATA are set, then the client knows at
    the very least that the change attribute is monotonically increasing,
    which is sufficient to resolve the question of which value is the
    most recent.
NEW:
    If either NFS4_CHANGE_TYPE_IS_MONOTONIC_INCR,
    NFS4_CHANGE_TYPE_IS_VERSION_COUNTER, or
    NFS4_CHANGE_TYPE_IS_TIME_METADATA are set, then the client knows at
    the very least that the change attribute is strictly increasing,
    which is sufficient to resolve the question of which value is the
    most recent.
END

s13, Operations table:  The abbreviation EOL in the title line does not 
seem to be expanded anywhere (and isn't used in the table either).  It 
would be good to have table numbers for the tables.

s13, Operations table: Does not include IO_ADVISE ( and technically 
doesn't include ILLEGAL, and CB_ILLEGAL isn't in Callbacks).

s15.2.3:
>     If it cannot make that determination, it must set to false the one it
>     can and set to true the other.
The setting of true and false appears to be the inverse of the meaning 
implied in the previous part of the section.

s15.5.6/s15.5.6.1: Pointers into the appropriate parts of the NFS v4.1 
RFC would be helpful in giving the background needed to understand what 
is going on here.    The discussion of dense and sparse packing in 
s15.5.6.1 is particularly obscure if you are not very well versed in 
pNFS lore.

ss15.6 and 15.7: An overview of the LAYOUT* operations in the earlier 
part of the document would be helpful, as mentioned above, plus some 
pointers to parts of the NFSv4.1 document that ties in with the pNFS 
layout story would be helpful.

s19.2, [Quigley14]:  This is now RFC 7569.  Also I think this should be 
normative.

s19.2, [BL73]: Can you point me to a copy of this? I have found some 
closely related work which was originally published as MITRE Technical 
Report 2547 Vols I and II  at 
http://www.albany.edu/acc/courses/ia/classics/belllapadula1.pdf 
(belllapadula2.pdf) and in the Journal of Computer Security  but the 
original doesn't seem to be visible.

---

From: Tom Haynes <[email-masked]>
Date: Fri, 18 Dec 2015 20:28:36 -0800

> On Dec 13, 2015, at 11:22 AM, Elwyn Davies <[email-masked]> wrote:
> 
> Summary: Almost ready.  There are a fair number of minor nits and editorial suggestions.  The couple of 'minor issues' are predominantly questions that came into my mind that might be interesting to a reader/implementer but are probably unlikely to affect the performance of the protocol.  However, the comments on s11.2, s12.1, s13 and s15.2.3 appear to be actual omissions or errors.
> 
> Major issues:
> None.
> 

Hi Elwyn,

Thanks as always for making me think!

Replies are inline, I have some questions for you and Andy.

Hi Andy,

There is a question about Inter-Server Copy Security below!

> Minor issues:
> s4:  There is no discussion in s4 of the Named Attributes associated with a file and the restriction of server-to-server copy to 'regular files' seems to indicate that Named Attributes cannot be copied by this mechanism.  Is there anything to be said about getting the Named Attributes across?

Actually, from Section 5.8.1.2 of RFC 5661:

   o  The phrases "is an ordinary file" and "is a regular file" mean
      that the object's type attribute is NF4REG or NF4NAMEDATTR.

(I’ll quote from RFC 5661 and not RFC 7530 because of the pnfs aspects.)

> 
> s4/s9:  Does server-to-server copy interact (badly, or otherwise) with Labeled NFS?  Nothing is said, but I wonder whether there are issues around atomicity and MAC between the different servers for inter-server copy.

Good question - I think even though we’ve published the Labeled NFS to allow for heterogeneous MAC deployments, sites are going to run a specific variant.

In that model, I would expect the object label to travel with the object and still be applied on the destination until modified by someone with those capabilities.

For the other model, the object label would control whether the file could be copied to another system or not. And if that system had a different MAC model, then according to the requirements in Section 3.3 of RFC 7204:

   A negotiation scheme SHOULD be provided, allowing systems from
   different Label Formats to agree on how they will interpret or
   translate each other's foreign labels.  Multiple concurrent
   agreements may be current between a server and a client.

> 
> s4.10.1.1.1: Size and reuse for random number used as a shared secret for inter-server copy.
> No advice is given on the desirable size/length of the random number or the risks or otherwise of reusing the same context for multiple file copies.  This maybe a non-issue - I defer to those with more security clue than me.

Back to RFC 7530, 3.2.1.1, when we had a similar discussion in the WG about the required algorithms fodeplying Kerberos:

   At the time this document was specified, the Advanced Encryption
   Standard (AES) with HMAC-SHA1 was a required algorithm set for
   Kerberos V5.  In contrast, when NFSv4.0 was first specified in
   [RFC3530], weaker algorithm sets were REQUIRED for Kerberos V5, and
   were REQUIRED in the NFSv4.0 specification, because the Kerberos V5
   specification at the time did not specify stronger algorithms.  The
   NFSv4 specification does not specify required algorithms for Kerberos
   V5, and instead, the implementer is expected to track the evolution
   of the Kerberos V5 standard if and when stronger algorithms are
   specified.

3.2.1.1.1.  Security Considerations for Cryptographic Algorithms in
            Kerberos V5

   When deploying NFSv4, the strength of the security achieved depends
   on the existing Kerberos V5 infrastructure.  The algorithms of
   Kerberos V5 are not directly exposed to or selectable by the client
   or server, so there is some due diligence required by the user of
   NFSv4 to ensure that security is acceptable where needed.  Guidance
   is provided in [RFC6649] as to why weak algorithms should be disabled
   by default.

I.e., I would prefer to not specify a policy on size and reuse of the random number as a shared secret. Well, strike that, the random number should not be reused and the length is determined by the algorithm used to generate that secret.

I can craft text to that effect.

> General: bytes or octets?

RFC 5661:

   Byte:  In this document, a byte is an octet, i.e., a datum exactly 8
      bits in length.

So bytes.

> Abstract: Probably ought to expand i/O.

done

> 
> s1/s1.1: I think you could safely delete the s1.1 header leaving the text as the body of s1 - this is generally considered better practice than leaving s1 itself empty.

done

> 
> s1.2, 3rd bullet: s/protocols.  I.e.,/protocols, that is/; s/apply/apply only/
Done

> 
> s1.4:  The overview doesn't cover the two LAYOUT related operations and there is is no section describing what their usage might be in with sections 4-10.
> 

1.3.7.  Layout Enhancements

   In the parallel NFS implementations of NFSv4.1 (see Section 12 of
   [RFC5661]), the client cannot communicate back to the metadata server
   any errors or performance characteristics with the storage devices.
   NFSv4.2 provides two new operations to do so respectively: LAYOUTERROR
   (see Section 15.6) and LAYOUTSTATS (see Section 15.7).

> s1.4: Similarly, there is noting about the CLONE operation.

1.3.1.  Server Side Clone and Copy

   A traditional file copy of a remotely accessed file, whether from one
   server to another or between locations in the same server, results in
   the data being put on the network twice - source to client and then
   client to destination.  New operations are introduced to allow
   unnecessary traffic to be eliminated:

   o  The intra-server clone feature allows the client to request a
      synchronous cloning, perhaps by copy-on-write semantics.

   o  The intra-server copy feature allows the client to request the
      server to perform the copy internally, avoiding unnecessary
      network traffic.

   o  The inter-server copy feature allows the client to authorize the
      source and destination servers to interact directly.

> 
> s1.4.1, para 1: s/remotely accessed/remotely accessed file/; s/location/locations/

done

> 
> s1.4.1: (very nitty!) Suggest making the descriptions of the two cases (intra- and inter-server) into bulleted paragraphs to make it clearer that they are separate features.
> 

Done

> s1.4.2: (as with the Abstract) expand I/O on first occurrence.

Done

> s1.4.2: It would be worth putting in the reference for posix_fadvise here.

Done

> 
> s1.4.3: If you write the data in the hole, it isn't really a hole ;-) ….

Ha!

> Such holes are typically transferred as 0s when read from the file.

Done

> 
> s1.5: Suggest s/I.e., READ becomes either/For instance, READ would have to be replaced or supplemented by, say, either/

Done

> 
> s2, last bullet: Need to expand pNFS on first use (and maybe remind readers that it is a feature of NFS4.1 - Section 12 of RFC 5661)

Done

> 
> s2, last bullet: s/metadata sever/metadata server/ - again a pointer to (say) Sections 1.7.2.2 and 12.2.2 of RFC 5661 would clarify what a metadata server is.
> 

Done

> I completely misread this on first pass, but I understand that it is correct.  Having checked with s15.3 and thought a bit more about it, it is the 'copy from a given destination' that threw me - I guess it means 'the copy will be made from' rather than 'the file being copied from the destination'... Doh!
>> A client sends this
>   COPY_NOTIFY:  Used by the client to request the source server to authorize a
>      future file copy that will be made by a given destination server on behalf of the given
>      user.  (Section 15.3)
> END

done

> 
> s4.2.2, para 5:  s/support all these operations/support these operations/ ('all' is confusing given that only two are then explicitly mentioned).
> 

done - BTW note that we had some WG revisions made to introduce the CLONE operation here. Those
changes are considered part of this review cycle. In other words, please let me know when you want
a revised draft copy published.

> s4.3, para 1:  s/Inter-server copy is driven/The specification of inter-server copy is driven/
> 

done

> s4.4.1, last para: s/The source MUST equate/The source MUST interpret/

done

> s4.6/Figures 4 and 5: Need a 'key' to explain os1 and os2.

Done in that I expanded the names in the figure and also made it clear which wa being released

> s4.7.2:  Adding a reference to Section 15.3(.3) would help.

Went with 15.3 - let me know if you’d like 15.3.3 better. 

> 
> s4.7.3, para 2: idnits identifies RFC 2616 as obsoleted by RFC 7230, etc.  A more recent ref is desirable.

Done

> 
> s4.8, para after code fragment: LDAP and NIS  need to be expanded (DNS and URL are well-known).

Done

> s4.9, para 3: Is it possible to add a little explanation as to *why* seqid = 0 is ambiguous?  My limited knowledge doesn't grok this.
> 

The stateid might be that of a lock, which has the provision that it cannot be 0

Section 8.2.2 of RFC 5661:

   When such a set of locks is first created, the server returns a
   stateid with seqid value of one.  On subsequent operations that
   modify the set of locks, the server is required to increment the
   "seqid" field by one whenever it returns a stateid for the same
   state-owner/file/type combination and there is some change in the set
   of locks actually designated.  In this case, the server will return a
   stateid with an "other" field the same as previously used for that
   state-owner/file/type combination, with an incremented "seqid" field.
   This pattern continues until the seqid is incremented past
   NFS4_UINT32_MAX, and one (not zero) is the next seqid value.

Let me know if you want a citation here (and a little bit of explanatory text).

Note, RFC 5661 uses “zero” and not “0”. I’ve changed this text to match.

> s4.10: Is it possible to provide an abstract definition of 'structured privilege'?  The rpcsec-gssv3 draft appears to punt on this, pointing to the 'example' in the NFSv4.2 draft.  I think I get the idea but a succinct definition would help I believe.   I guess the definition ought to be in the rpcsec-gss document and referenced from this doc.
> 

^^ Andy???

> s4.10.1.1.1, 2nd bullet: Need to expand QOP.

Andy, RFC 2203 uses this term, but does not expand it. And RFC 5403 does not use it.

It is a field in one of the structures?

> s4.10.1.2, para 2: s/uiniquely/uniquely/

Done

> s5, title: s?IO?I/O?

fixed

> 
> s6.1: This heading could be deleted turning the text in 6.1 into Section 6 which is then not empty.
> 

Done

> s6.1: The term 'inode' is used four times in this section.  Whilst this is well understood, it is strictly associated with *nix file systems. It would be desirable to find an alternative term or, if you can't think of suitable short generic term (I spent a little time thinking about it and couldn't think of one immediately), some weasel words added to the first occurrence saying that it is intended to cover equivalent structures in other sorts of filing system.

Let me try to weasel!

I’ve related it to metadata.

> s6.1, para 2: s/can thought as holes/can thought of as holes/

can be thought of as holes

> 
> s6.1, para 4:  s/couple/few/  ('couple hundred' is a USA specific colloquialism - UK would use 'couple of’)

done

> 
> s6.1, last para: s/punching.  I.e., an application/punching, where an application/
> 

done

> s7, para 1: s/One example is the posix_fallocate/One example is the posix_fallocate operation/
> 

Done

>   space_freed  This attribute reports the space that would be freed when a file is

Done

>       block corruption.  For both pieces of data, a useful property would be
>       that the allowed values are specially selected so that if passed across the
>       the same (32 wide) bit pattern in both architectures, making it inappropriate.
> END

Done

> PS: The example is relevant to 32 bit memory architectures... It has never occurred to me to ask if there are 64 bit big and little endian architectures!  Well the IA-64 is bi-endian...
> 
> s8.3:  The pictures of the memory patterns don't match the specification in that the guard pattern appears to be at octet offset 4 in each ADB - You can't tell where the checksum is from the pictures, but as specified there would be a 4 octet gap between the guard pattern and the checksum - I presume this is intentional. Would it be guaranteed to be zero?
> 

Not on purpose - does this work?

   Further, assume the application writes a single ADB at 16k, changing
   the guard pattern to 0xcafedead, we would then have in memory:

       0k ->   (4k - 1) : 00 00 00 00 ... fe ed fa ce 00 00 ... 00
       4k ->   (8k - 1) : 00 00 00 01 ... fe ed fa ce 00 00 ... 00
       8k ->  (12k - 1) : 00 00 00 02 ... fe ed fa ce 00 00 ... 00
      12k ->  (16k - 1) : 00 00 00 03 ... fe ed fa ce 00 00 ... 00
      16k ->  (20k - 1) : 00 00 00 04 ... ca fe de ad 00 00 ... 00
      20k ->  (24k - 1) : 00 00 00 05 ... fe ed fa ce 00 00 ... 00
      24k ->  (28k - 1) : 00 00 00 06 ... fe ed fa ce 00 00 ... 00
         ...
     396k -> (400k - 1) : 00 00 00 63 ... fe ed fa ce 00 00 ... 00

> s9.1:  Again it would be best to delete the title of s9.1 and leave the text as s9.
> 

Done

> s9.1, para 2: Expand ACL please.

Done

> 
> s9.1/s9.6.1.3: I am dubious about referring back to the requirements doc [RFC7204] for definitions (rather than indicating what requirements were met/not met) .  For the ref in s9.1, I think that the MAC definition in RFC 4949 would suffice.

Done

> [I noted when reviewing the rpcsec-gssv3 draft a couple of days ago that it makes *normative* reference to RFC 7204 - this is even more undesirable - my feeling is that it should be possible to find out what implementers need to know from the NFSv4.2 standard, other standards or the security glossary as there is no certainty that what is said in the requirements was actually put into the standard, which could cause confusion for future implementers.]  Is it possible to get everything an rpcsec-gssv3 implementer needs to know into this document?  My impression is that it is almost all there already.

Andy???

> 
> s9.2, MLS definition: RFC 2401 has been obsoleted by RFC 4301... can this be referenced instead?

MLS appears in RFC 2401 and not RFC 4301.

But I wasn’t aware of RFC 4949 - do you want to use it here as well?

> 
> s9.4: Expand DS and MDS on first occurrence (these should probably go back in s3 where metadata servers and data servers are referred to but without the abbreviations).

Oh, I don’t like using them at all. I think I was supposed to go back and expand them. :-)

> 
> s11.2, Table 2: The operation IO_ADVISE is missing from the table. [CAVEAT: I don't claim to have checked the possible error codes!] Aesthetically, this table would be better with horizontal separators between the operation items.

Done on the first part.

And the newer versions of xml2rfc has allowed me to add the horizontal separators

> 
> s12.1, Table 4:  The data types of clone_blksize (length4 vs uint32_t) and space_freed (length4 vs uint64_t) do not match between this draft and the XDR draft.

Fixed as per the email on the XDR draft.

> Monotonic is not really a good name for this I think.  This is because the technical definition is either non-increasing or non-decreasing so that it would theoretically cover situations where the change attribute doesn't actually change! IMO a better name would be NFS4_CHANGE_TYPE_STRICTLY_INCR.  This would imply that the value actually increases whenever the info changes.
> 

Researching this one!  Will get back to you...

> s13, Operations table:  The abbreviation EOL in the title line does not seem to be expanded anywhere (and isn't used in the table either).  It would be good to have table numbers for the tables.
> 

Yes, I think it was taken out in an earlier draft - striking.

Table numbers added

> s13, Operations table: Does not include IO_ADVISE

Added

> ( and technically doesn't include ILLEGAL, and CB_ILLEGAL isn't in Callbacks).

Added

> The setting of true and false appears to be the inverse of the meaning implied in the previous part of the section.

Agreed

> 
> s15.5.6/s15.5.6.1: Pointers into the appropriate parts of the NFS v4.1 RFC would be helpful in giving the background needed to understand what is going on here.    The discussion of dense and sparse packing in s15.5.6.1 is particularly obscure if you are not very well versed in pNFS lore.

Done - added a reference for the COMMIT semantics and the packing. 

> 
> ss15.6 and 15.7: An overview of the LAYOUT* operations in the earlier part of the document would be helpful, as mentioned above, plus some pointers to parts of the NFSv4.1 document that ties in with the pNFS layout story would be helpful.
> 

Note that we have been trying to shift from pulling in everything every minor version to just the bare minimum.

And I’ll note you are saying I’m not at that bar. :-)

Still not sure...

> s19.2, [Quigley14]:  This is now RFC 7569.  Also I think this should be normative.

Done

> 
> s19.2, [BL73]: Can you point me to a copy of this? I have found some closely related work which was originally published as MITRE Technical Report 2547 Vols I and II  at http://www.albany.edu/acc/courses/ia/classics/belllapadula1.pdf (belllapadula2.pdf) and in the Journal of Computer Security  but the original doesn't seem to be visible.
> 
> 

I don’t have a copy either - during the work on RFC 7569, Ran Atkinson provided this citation in the review process. Perhaps you can ask him? (Ask me offline and I’ll provide his email.)

---

From: "Adamson, Andy" <[email-masked]>
Date: Tue, 22 Dec 2015 15:30:00 +0000

> On Dec 18, 2015, at 11:28 PM, Tom Haynes <[email-masked]> wrote:
> 
> 
>> s4.10: Is it possible to provide an abstract definition of 'structured privilege'?  The rpcsec-gssv3 draft appears to punt on this, pointing to the 'example' in the NFSv4.2 draft.
>>  I think I get the idea but a succinct definition would help I believe.   I guess the definition ought to be in the rpcsec-gss document and referenced from this doc.
>> 
> 

The succinct definition is here:

From draft-ietf-nfsv4-rpcsec-gssv3-14 Section 2.7.1.4.  Structured Privilege Assertions first sentence, first paragraph:

"A structured privilege is an RPC application defined privilege.” 

and at the end of the first paragraph:

"Encoding, server verification and any policies for structured privileges are described by the RPC application definition.”

NFSv4.2 is the RPC application that defines the inter server to server copy structured privileges.

There is really nothing else to add to the definition.

> Andy, RFC 2203 uses this term, but does not expand it.

Actually, it does in a very round-about manner.

rfc2203:

5.2.1.  Mechanism and QOP Selection

   There is no facility in the RPCSEC_GSS protocol to negotiate GSS-API
   mechanism identifiers or QOP values. At minimum, it is expected that
   implementations of the RPCSEC_GSS protocol provide a means to:

   *    specify mechanism identifiers, QOP values, and RPCSEC_GSS
        service values on the client side, and to

   *    enforce mechanism identifiers, QOP values, and RPCSEC_GSS
        service values on a per-request basis on the server side.

   It is necessary that above capabilities exist so that applications
   have the means to conform the required set of required set of
   <mechanism, QOP, service> tuples (See the section entitled Set of GSS-API Mechanisms).
                                                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

6.  Set of GSS-API Mechanisms

   RPCSEC_GSS is effectively a "pass-through" to the GSS-API layer, and
   as such it is inappropriate for the RPCSEC_GSS specification to
   enumerate a minimum set of required security mechanisms and/or
   quality of protections.

so QOP is "Quality of Protection"

> And RFC 5403 does not use it.
> 

Here is are some references:

rfc2743  "Generic Security Service Application Program Interface Version 2, Update 1"

Section 1.2.4:  Quality of Protection

   Some mech_types provide their users with fine granularity control
   over the means used to provide per-message protection, allowing
   callers to trade off security processing overhead dynamically against
   the protection requirements of particular messages. A per-message
   quality-of-protection parameter (analogous to quality-of-service, or
   QOS) selects among different QOP options supported by that mechanism.
   On context establishment for a multi-QOP mech_type, context-level
   data provides the prerequisite data for a range of protection
   qualities.

rfc4121: "The Kerberos Version 5 Generic Security Service Application Program Interface (GSS-API) Mechanism: Version 2"

Section 3.  Quality of Protection

   The GSS-API specification [RFC2743] provides Quality of Protection
   (QOP) values that can be used by applications to request a certain
   type of encryption or signing.  A zero QOP value is used to indicate
   the "default" protection; applications that do not use the default
   QOP are not guaranteed to be portable across implementations, or even
   to inter-operate with different deployment configurations of the same
   implementation.  Using a different algorithm than the one for which
   the key is defined may not be appropriate.  Therefore, when the new
   method in this document is used, the QOP value is ignored.

            ……...

>> [I noted when reviewing the rpcsec-gssv3 draft a couple of days ago that it makes *normative* reference to RFC 7204 - this is even more undesirable

Starting with draft-ietf-nfsv4-rpcsec-gssv3-14, rfc7204 is an informative reference, and each reference includes a section number.

>> - my feeling is that it should be possible to find out what implementers need to know from the NFSv4.2 standard, other standards or the security glossary as there is no certainty that what is said in the requirements was actually put into the standard, which could cause confusion for future implementers.]

the information that draft-ietf-nfsv4-rpcsec-gssv3-14 references in rfc7402 is ‘big picture’ info:

1.  Introduction and Motivation

   Labeled NFS (see Section 9 of [NFSv4.2]) uses an MLS policy with
   Mandatory Access Control (MAC) systems as defined in [RFC4949].
   Labeled NFS stores MAC file object labels on the NFS server and
   enables client Guest Mode MAC as described in Section 4.3 of
   [RFC7204].  RPCSEC_GSSv3 label assertions assert client MAC process
   subject labels to enable Full Mode MAC when combined with Labeled NFS
   as described in Section 3.3 of [RFC7204].

1.1.  Added Functionality
           ………..
  o  Security labels for Full Mode security type enforcement, and other
      labeled security models (See Section 5.5.1 in [RFC7204]).

  An option for enumerating server supported label format specifiers
   (LFS) is provided.  See Section 2 and Section 3.3 in [RFC7204] for
   detail.

>>   Is it possible to get everything an rpcsec-gssv3 implementer needs to know into this document? 
>>  My impression is that it is almost all there already.

I think WRT this issue, draft-ietf-nfsv4-rpcsec-gssv3-14 does give everything an implementor of rpcsec-gssv3 neeeds to know.

—>Andy

---

From: "Adamson, Andy" <[email-masked]>
Date: Tue, 22 Dec 2015 16:27:32 +0000

> On Dec 22, 2015, at 10:30 AM, Adamson, Andy <[email-masked]> wrote:
> 
>> 

Tom - I’ll review Section 9.6 "MAC Security NFS Modes of Operation" of draft-ietf-nfsv4-minorversion2 and suggest some changes (if needed) so that draft-ietf-nfsv4-rpcsec-gssv3 can simply reference draft-ietf-nfsv4-minorversion2 for MAC security issues and get rid of the RFC7204 reference.

—>Andy