NFSv4.0 Migration: Specification Update
draft-ietf-nfsv4-rfc3530-migration-update-08

[Ballot comment]
Thanks for addressing my DISCUSS.

---

My comments are about the example given in Section 4.9.

I understand from 4.2 that the requirements for the construction of the client id are:

1) It should be unique per client.
2) It should persist through reboots.

As best I can tell, embedding the client's IP address in the client id is not a requirement (but I admit to not fully understanding NFS!). So why is it suggested that the client's network address be embedded in the client id?

There are also a few privacy-related issues with the example:

- Some clients will change their IP addresses over time to avoid being tracked. By suggesting that some prior address be used in the client id, there is an implied requirement on the client to maintain a history of previously used addresses, which could be exploited for tracking purposes.

- Permanent device identifiers (such as a serial numbers) should not be embedded in a client id on the wire, again to avoid facilitating tracking by any other party that knows the serial number.

It seems to me that to avoid all of the issues above, perhaps a better example to provide would be hash(some client secret, some source of uniqueness, server identity). That gives the client id a good chance of being unique without exposing other identifiers related to the client. And then if the existing guidance about saving and re-using the value is followed, it won't be necessary to try to shoehorn in an old IP address or persistent device identifiers when the clientid needs to be regenerated.

[Ballot comment]
[ I've cleared my discuss since discussion is happening. I moved the following two discuss points into the comment section:

This draft recommends the use of the uniform client-ID string approach. I admit to not being an NFS expert, but that seems to add a lot of complexity. It seems counter to advice in 7530. Section 4.7 of this draft points out that this may create interop problems with some servers. It seems to increase the privacy impact of persistent and potentially user and hardware identifying client-ID strings. There seems to be an issue of balancing harms here. I'd like to see some text describing how the harm avoided by the uniform approach balances out with the other issues.

The security considerations seem incomplete. This draft makes a number of normative changes and clarifications that are likely to introduce new security and/or privacy considerations that are not mentioned. This is especially true for the guidance about using uniform client-IDs.]


I support Alissa's DISCUSS comments concerning the privacy implications of a persistent client ID.  I am also concerned that the suggested approaches might help enable client fingerprinting.

- 4.2 (occurs twice)
The text says clients MAY send different strings to different servers. I think there may be privacy and tracking implications here, even if the client-ID is constructed without IP addresses or hardware identifiers. Is MAY strong enough? This ties in with the recommendations throughout the document about using persistent IDs across multiple servers. Perhaps there should be guidance to use different strings in general, except in cases where state-sharing is likely to come into play? (e.g. across completely different mount points?)

-4.2, paragraph starting with "As a security measure"
It might be helpful to briefly describe the security concern.
-- paragraph starting with "The difficulty is more severe..."
I think this paragraph warrants some normative guidance.

- 4.3:
How terrible is it if client state is prematurely deleted? Much of this draft, including the guidance to use uniform IDs across servers, seem to treat premature deletion as an ultimate harm, and do not balance that risk against the privacy and complexity issues that it may create.

- 4.7, 2nd bullet list:
How does the client know whether a server might return NFS4ERR_MOVED?

-7.5, 2nd bullet:
"trust relationship" by itself doesn't mean much. Who trusts what to do what?


Editorial:

- 3, paragraph starting with "Specification of requirements for the server..."
The first sentence hard to parse. The last sentence is also confusing. I think you mean to say that NFV4.0 non-normatively encourages the practice? A careless reader is likely to interpret "not 'RECOMMENDED'" as "NOT RECOMMENDED".

-3, paragraph starting with "to further complicate matters":
The paragraph uses confusing language. I _think_ you mean that servers have assumed a particular client implementation pattern, and can’t work with others. But it sounds like it says clients have universally adopted a particular pattern, in which case the interop problem doesn’t make sense.

-3, 4th paragraph from end:
Please don't use 2119 keywords to talk about how the other text uses 2119 keywords. Or at least put "RECOMMENDs" in quotes.

- 4.2, bullet entry starting with "The verifier is a client incarnation identifier..."
The second sentence is hard to parse. (The original version was hard, and this version is harder.)
--bullet starting with "The string MAY...":
redundant to similar guidance earlier in section.
-- paragraph starting with "Distinct servers MAY assign..."
What do you mean by "trunking"? I don't see the term defined anywhere.

- 4.6, "... cause us to RECOMMEND use of the uniform client id string"
I don't think that sentence should use the 2119 "RECOMMEND" keyword.

- 4.8: The repeated use of first person pronouns in this section (and elsewhere) is confusing. It's not always clear if "we" means the draft authors, implementors, or the implementation itself.
-- paragraph before 2nd bullet list:
First sentence is hard to parse.

- 7.4.5, first paragraph:
What does it mean to "make the following notations"?

- 7.5, third bullet:
First sentence is hard to parse.

- section 7.6 and 8:
The structure is confusing. 7.6 says it modifies the security considerations, but is not clear whether that means the security considerations in 7530, or in this document. 8 says "It is to be modified in section 7.6", without a clear antecedent for "It".

[Ballot comment]
I agree with Alissa's discuss about client ids and
apologies also from me for not spotting that in 7530.  The
persistent-across-reboots-forever thing that this seems to
be encouraging (if I'm reading it correctly) is just a bit
much really. But maybe we're lucky in that we now have a
chance to improve on that. (Further apologies for not
having actually had time to read this properly, I'm happy
to be part of a discussion on how what to do here if
that helps though and will read it properly if involved
in that;-)

[Ballot comment]
Quick update from Victor Kuarsingh, part of the OPS DIR review:
I am still going through the draft.  I is taking me long then normal since the writing style is making it hard to parse faster.  So far, here is where my analysis is going.

    edits needed to fix up language (very conversational in nature – not sure if that’s what the IETf normally wants)
    it’s hard to extract the updated requirements in the document as they appear both in bullet points, and in paragraphs (thus far)
    Quite a bit of time spent on what should not be done by servers/systems (seems helpful).
    However, the entire document was focused on fixing implementation problems/challenges conducting migrations for NFSv4.0 which should be benefiting (given it’s based on real world implementation challenges)
    I had pre-scanned the document ahead of time, and it appears the guidance in section 5/6 will be where the meat of the discussion is.
    Nothing really bad jumps out at me just yet (other then hard to follow).

[Ballot discuss]
This draft recommends the use of the uniform client-ID string approach. I admit to not being an NFS expert, but that seems to add a lot of complexity. It seems counter to advice in 7530. Section 4.7 of this draft points out that this may create interop problems with some servers. It seems to increase the privacy impact of persistent and potentially user and hardware identifying client-ID strings. There seems to be an issue of balancing harms here. I'd like to see some text describing how the harm avoided by the uniform approach balances out with the other issues.

The security considerations seem incomplete. This draft makes a number of normative changes and clarifications that are likely to introduce new security and/or privacy considerations that are not mentioned. This is especially true for the guidance about using uniform client-IDs.

[Ballot comment]
I support Alissa's DISCUSS comments concerning the privacy implications of a persistent client ID.  I am also concerned that the suggested approaches might help enable client fingerprinting.

- 4.2 (occurs twice)
The text says clients MAY send different strings to different servers. I think there may be privacy and tracking implications here, even if the client-ID is constructed without IP addresses or hardware identifiers. Is MAY strong enough? This ties in with the recommendations throughout the document about using persistent IDs across multiple servers. Perhaps there should be guidance to use different strings in general, except in cases where state-sharing is likely to come into play? (e.g. across completely different mount points?)

-4.2, paragraph starting with "As a security measure"
It might be helpful to briefly describe the security concern.
-- paragraph starting with "The difficulty is more severe..."
I think this paragraph warrants some normative guidance.

- 4.3:
How terrible is it if client state is prematurely deleted? Much of this draft, including the guidance to use uniform IDs across servers, seem to treat premature deletion as an ultimate harm, and do not balance that risk against the privacy and complexity issues that it may create.

- 4.7, 2nd bullet list:
How does the client know whether a server might return NFS4ERR_MOVED?

-7.5, 2nd bullet:
"trust relationship" by itself doesn't mean much. Who trusts what to do what?


Editorial:

- 3, paragraph starting with "Specification of requirements for the server..."
The first sentence hard to parse. The last sentence is also confusing. I think you mean to say that NFV4.0 non-normatively encourages the practice? A careless reader is likely to interpret "not 'RECOMMENDED'" as "NOT RECOMMENDED".

-3, paragraph starting with "to further complicate matters":
The paragraph uses confusing language. I _think_ you mean that servers have assumed a particular client implementation pattern, and can’t work with others. But it sounds like it says clients have universally adopted a particular pattern, in which case the interop problem doesn’t make sense.

-3, 4th paragraph from end:
Please don't use 2119 keywords to talk about how the other text uses 2119 keywords. Or at least put "RECOMMENDs" in quotes.

- 4.2, bullet entry starting with "The verifier is a client incarnation identifier..."
The second sentence is hard to parse. (The original version was hard, and this version is harder.)
--bullet starting with "The string MAY...":
redundant to similar guidance earlier in section.
-- paragraph starting with "Distinct servers MAY assign..."
What do you mean by "trunking"? I don't see the term defined anywhere.

- 4.6, "... cause us to RECOMMEND use of the uniform client id string"
I don't think that sentence should use the 2119 "RECOMMEND" keyword.

- 4.8: The repeated use of first person pronouns in this section (and elsewhere) is confusing. It's not always clear if "we" means the draft authors, implementors, or the implementation itself.
-- paragraph before 2nd bullet list:
First sentence is hard to parse.

- 7.4.5, first paragraph:
What does it mean to "make the following notations"?

- 7.5, third bullet:
First sentence is hard to parse.

- section 7.6 and 8:
The structure is confusing. 7.6 says it modifies the security considerations, but is not clear whether that means the security considerations in 7530, or in this document. 8 says "It is to be modified in section 7.6", without a clear antecedent for "It".

[Ballot comment]
No objection to the publication of this document, but I do have a few non-blocking points:

1. I support Alissa's DISCUSS on the privacy issues surrounding the client ID and will be following the discussion intently.

2. It would be nice if pointers to the actual definition of data types like verifier4 and cb_client4 were provided.

[Ballot discuss]
Per my comment below, it seems like there are some fairly significant privacy considerations related to the choice of how the client id is constructed. I think these need to be described in the document so implementors are aware of them. (And my bad for not noticing this before the publication of RFC 7530, since they would have applied there as well.)

[Ballot comment]
My comments are about the example given in Section 4.9.

I understand from 4.2 that the requirements for the construction of the client id are:

1) It should be unique per client.
2) It should persist through reboots.

As best I can tell, embedding the client's IP address in the client id is not a requirement (but I admit to not fully understanding NFS!). So why is it suggested that the client's network address be embedded in the client id?

There are also a few privacy-related issues with the example:

- Some clients will change their IP addresses over time to avoid being tracked. By suggesting that some prior address be used in the client id, there is an implied requirement on the client to maintain a history of previously used addresses, which could be exploited for tracking purposes.

- Permanent device identifiers (such as a serial numbers) should not be embedded in a client id on the wire, again to avoid facilitating tracking by any other party that knows the serial number.

It seems to me that to avoid all of the issues above, perhaps a better example to provide would be hash(some client secret, some source of uniqueness, server identity). That gives the client id a good chance of being unique without exposing other identifiers related to the client. And then if the existing guidance about saving and re-using the value is followed, it won't be necessary to try to shoehorn in an old IP address or persistent device identifiers when the clientid needs to be regenerated.

(Via drafts-lastcall-comment@iana.org): IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-nfsv4-rfc3530-migration-update-07.txt, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any IANA actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, IANA does not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
IANA Specialist
ICANN

The following Last Call announcement was sent out:

From: The IESG
To: "IETF-Announce"
CC: spencer.shepler@gmail.com, mls.ietf@gmail.com, nfsv4-chairs@ietf.org, draft-ietf-nfsv4-rfc3530-migration-update@ietf.org, nfsv4@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (NFSv4.0 migration: Specification Update) to Proposed Standard


The IESG has received a request from the Network File System Version 4 WG
(nfsv4) to consider the following document:
- 'NFSv4.0 migration: Specification Update'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2016-01-18. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The migration feature of NFSv4 allows for responsibility for a single
  filesystem to move from one server to another, without disruption to
  clients.  Recent implementation experience has shown problems in the
  existing specification for this feature in NFSv4.0.  This document
  clarifies and corrects RFC7530 (the NFSv4.0 specification) to address
  these problems.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530-migration-update/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530-migration-update/ballot/


No IPR declarations have been submitted directly on this I-D.

This shepherding write-up is for the following I-D:

draft-ietf-nfsv4-rfc3530-migration-update-07

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

Proposed Standard


(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  The migration feature of NFSv4 allows for responsibility for a single
  filesystem to move from one server to another, without disruption to
  clients.  Recent implementation experience has shown problems in the
  existing specification for this feature in NFSv4.0.  This document
  clarifies and corrects RFC7530 (the NFSv4.0 specification) to address
  these problems.

Working Group Summary

  This I-D represents strong working group consensus and is derived
  from implementation experience of the NFSv4 migration capabilities and
  is therefore representative of needed clarification in specification
  for interoperable implementation.

Document Quality

  As mentioned, this work is derived from implementation experience and
  relates to the needs of the community of NFSv4 implementors such that
  they can create effective and interoperable implementations in the
  context of migration support.

Personnel

  Document Shepherd: Spencer Shepler
  Area Director: Martin Stiemerling

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  I have reviewed the document in full and have followed the working
  group discussions during the development and review of the document.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?

  I am comfortable with the document's content and breadth/depth of
  coverage of the topic.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.

  Not applicable.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No issues.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  No.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  The working group is in full support of the document.
 
(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.

  None applicable.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  Not applicable.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  Not applicable.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.

  No.  This is a clarification/addition to the NFSv4 RFC and will not
  change its current status.

(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  Not applicable.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.

  Not applicable

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  Not applicable.