IETF conflict review for draft-williams-exp-tcp-host-id-opt
conflict-review-williams-exp-tcp-host-id-opt-02

I absolutely agree that a protocol -- even an experimental one -- that facilitates identification of individual hosts behind a NAT should go through the IETF consensus process.

Here are comments for the ISE to consider:

- The abstract says it in the first sentence:
"Recent IETF proposals have identified benefits to more distinctly"

This sentence is trying to make a statement into the direction that the IETF is endorsing host identification. This is not true and therefore this sentence must be removed or changed in wording. Probably the authors mean: "Recent  proposals  discussed in the IETF have identified benefits to more distinctly..."

- Further, this draft is arguing in favor of letting middleboxes adding the proposed TCP option. This is problematic for multiple issues, such as adding a TCP option will very likely cause packets to grow beyond the path MTU and TCP option space is limited and extensively used already by TCP options added by the end hosts. The draft acknowledges both issues and discusses them briefly.
However, it is clear by now that the TCP option space is almost used by modern TCP implementations to signal the properties of a TCP connection (especially with MPTCP). Adding another option will be potentially not possible, unless such a middlebox is going to remove an option that has been added by an end host. 

- Section 4.2.2 is discussing problematic issues when persistent TCP connections are used which are used by multiple application sessions at the same time. The text gives recommendations, but the recommendations will end up in a very complex, error prone setup, where potentially user traffic is being miss-classified. E.g. in the case the middlebox is sending nonetheless traffic of multiple users over the same TCP connection. 

- Section 4.3, page 10, limits the use of host_ids to middlebox only. The mechanism 1 (stripping off others host_id) options will not let arbitrary TCP end points to use this option for their own use. This falls in the same category as usually discussed that adding options in the data path will end up with removing options inserted by end hosts. 

- Section 4.4 disucsses that the order of multiple HOST_IDs cannot be guaranteed in the transit. However, it makes the recommendation to just concatenate any appearance of multiple HOST_IDs and use the concatenated value as the HOST_ID. How does this ensure that there are no two HOST_ID by different TCP connections that collide? It basically does not ensure this. 

- Section 7:
 - NATs do not provide any form of privacy, as there so many other mechanisms to determine the user of a data flow. 
 - This section is not discussing the real security impacts, e.g., what is the result if any device is forging the information in the HOST_ID? Or can this be used to breach privacy of users, because a stable identifier is used across TCP sessions and applications?

Fully agree with the DNP response and Martin's comments.