Subject: [nfsv4] Alissa Cooper's No Objection on draft-ietf-nfsv4-rfc3530-migration-update-08: (with COMMENT)

From: "Alissa Cooper" <[email-masked]>
Date: Tue, 10 May 2016 06:22:05 -0700

Alissa Cooper has entered the following ballot position for
draft-ietf-nfsv4-rfc3530-migration-update-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-nfsv4-rfc3530-migration-update/

----------------------------------------------------------------------
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.