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

The following approval message was sent
From: The IESG
To: draft-williams-exp-tcp-host-id-opt@ietf.org,
    rfc-ise@rfc-editor.org,
    "Nevil Brownlee"
Cc: "The IESG" ,
    iana@iana.org,
    "IETF-Announce"
Subject: Results of IETF-conflict review for draft-williams-exp-tcp-host-id-opt-07

The IESG has completed a review of draft-williams-exp-tcp-host-id-opt-07
consistent with RFC5742.


The IESG recommends that 'Experimental Option for TCP Host
Identification'  NOT be
published as an Experimental RFC.


The IESG has concluded that this document violates IETF procedures about
pervasive monitoring (RFC 7258) and should therefore not be published
without IETF review and IESG approval. This work is related to IETF work
done in the INTAREA WG.

The IESG would also like the Independent Submissions Editor to review the
comments in the datatracker related to this document and determine
whether or not they merit incorporation into the document. Comments may
exist in both the ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-williams-exp-tcp-host-id-opt/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
Update: I find Alissa's and Stephen's DISCUSS positions convincing.

I'd prefer the abstract to read less like an IETF endorsement of identifying hosts behind NATs. (But not so strongly to block things, given the updates.)

[Ballot discuss]
I think the previous conflict review response was correct, not the current one.

I think the way that this spec justifies the design decisions that may allow the HOST_ID option to be used for pervasive monitoring can be summarized as: the option merely puts back in host identification information that a middlebox otherwise would have stripped out. I don't think this is really satisfactory. RFC 7258 doesn't say that we will work to ensure that pervasive monitoring remains only as easy or hard as it was before the deployment of CGNs or application proxies. It says that we will work to mitigate pervasive monitoring. So from the perspective of mitigating PM, the loss of unique host identification on the egress side of address-sharing devices is a virtue.

Of course, the motivations for re-introducing host uniqueness are well-documented. But this draft doesn't link the specification of the option to those motivations in a way that provides the justification that RFC 7258 requires, IMO. In particular, the document allows for the HOST_ID to contain an IP address or subnet, optionally together with a TCP port number. Under some circumstances using the option in these ways leaks information that allows for correlating the activities of the host more broadly than if the option were not used -- e.g., if an application proxy uses the option in this way, then the host traffic on the egress side of the proxy can be newly correlated with the host's traffic that does not pass through the proxy. If instead the proxy used a random, locally unique ID in the option, this type of correlation would not be re-introduced. So why should the option support embedding an IP address and TCP port, if all it needs to provide is local uniqueness for the hosts sharing the public address? Doesn't an opaque locally unique ID suffice for the three use cases listed in the document?

[Ballot comment]
First, I agree with Alissa, Stephen, and Ben.

Secondly, I do not consider this specific design to be an improvement in the Internet, and that is the reason why I am balloting an Abstain in this case. The Abstain has no significance in the case of this type of a document going through the RFC Editor, but I wanted to be on record in disagreeing with this document.

Overall, I understand the need to protect against denial-of-service attacks and other issues, without causing collateral damage for other users behind the same IP address. But, I do not believe we should be increasing the attack surface against the Internet users at large. The potential for privacy violations from criminals, entities involved in collecting far too much information from web users, and illegally operating surveillance organisations is just too great.

One additional note: If you want to publish a good document, there might be some other designs, such as the random ID variant that have smaller worries than the current design. I am not saying those designs would be good, or that I would change my position, but those other designs would certainly be a marked improvement over the current document.

[Ballot discuss]

I'd also like to discuss this one some more. So far, I've looked quickly
at the diff between the last one we reviewed and the latest version.
That's [1].

That diff absolutely does not convince me that the draft is now only
describing something already deployed. For example the latest one
still says "...intended to allow broad deployment of the mechanism
on the public Internet." That remains entirely inconsistent with
IETF BCPs and so I believe we should revert to the previous DNP
response to the ISE.

If we reach consensus on that, then I'm not sure if we should try
to identify all the "badness" in -07 or if we should just say "please
DNP, no material change from our POV." I think the latter is more
appropriate but maybe this is something we ought discuss with
Nevil - what's the right/best kind of IESG response in such a
situation. Which leads me on to...

Also - from the ballot it's not possible for an AD to determine
anything about why the ISE has returned this item. I think that
is also something about which it'd be good to chat with Nevil,
from a possible tooling POV but also from a transparency and
accountability perspective. I think when/if the ISE is interacting
with the IESG in cases like this, it would seem fairly obviously
beneficial if the ISE's perspective on what's changed was part
of the record. (Or perhaps the ISE's editorial board, I don't even
know which applies.)

The history of this overall set of documents and their authors'
doggedness in attempting to achieve publication as an RFC
(which is an entirely reasonable thing for authors to do) would
seem to indicate that we ought carefully consider if we're
collectively (IETF+ISE+RFCed) sending a message that all one
has to do is keep asking and you can get any bad idea out as
an RFC. I think we do not want that perception to spread.

    [1] https://www.ietf.org/rfcdiff?url1=draft-williams-exp-tcp-host-id-opt-05&url2=draft-williams-exp-tcp-host-id-opt-07

[Ballot discuss]
I'm not really sure how this is supposed to work when we change conflict review responses, so forgive me if I've balloted incorrectly given my comments below. Basically I don't think the document has fully resolved the issues raised in the previous conflict review. But I'm not arguing that the document conflicts with work in TCPM.

I think the way that this spec justifies the design decisions that may allow the HOST_ID option to be used for pervasive monitoring can be summarized as: the option merely puts back in host identification information that a middlebox otherwise would have stripped out. I don't think this is really satisfactory. RFC 7258 doesn't say that we will work to ensure that pervasive monitoring remains only as easy or hard as it was before the deployment of CGNs or application proxies. It says that we will work to mitigate pervasive monitoring. So from the perspective of mitigating PM, the loss of unique host identification on the egress side of address-sharing devices is a virtue.

Of course, the motivations for re-introducing host uniqueness are well-documented. But this draft doesn't link the specification of the option to those motivations in a way that provides the justification that RFC 7258 requires, IMO. In particular, the document allows for the HOST_ID to contain an IP address or subnet, optionally together with a TCP port number. Under some circumstances using the option in these ways leaks information that allows for correlating the activities of the host more broadly than if the option were not used -- e.g., if an application proxy uses the option in this way, then the host traffic on the egress side of the proxy can be newly correlated with the host's traffic that does not pass through the proxy. If instead the proxy used a random, locally unique ID in the option, this type of correlation would not be re-introduced. So why should the option support embedding an IP address and TCP port, if all it needs to provide is local uniqueness for the hosts sharing the public address? Doesn't an opaque locally unique ID suffice for the three use cases listed in the document?

[Ballot comment]
I strongly agree with both Ben and Kathleen.
The abstract reads as if the IETF has reached a consensus position,
which is not appropriate for an ISE document.

[Ballot comment]
I agree with Ben's point, especially in light of the described use cases.  Although this is just documenting what happens, it would be best if this does not sound like an endorsement of these practices.

[Ballot comment]
I'd prefer the abstract to read less like an IETF endorsement of identifying hosts behind NATs. (But not so strongly to block things, given the updates.)

[Ballot comment]
The authors have added text in Section 8.  Pervasive Monitoring Considerations that addresses aspects of RFC 7258. Plus added statements about what of what not should be used in the HOST_ID part.

[Ballot comment]
The authors have added text in Section 8.  Pervasive Monitoring Considerations that addresses RFC 7258. Plus added statements about what of what not should be used in the HOST_ID part.

Hi IESG folk:

This draft had its 5742 conflict review a while back, it raised
concerns for IESG. With that feedback, it's authors have revised
it to address those concerns, so now I'd like IESG to take another
look at it, please.

Cheers, Nevil

--
Nevil Brownlee (ISE), rfc-ise@rfc-editor.org

The following approval message was sent
From: The IESG
To: "Nevil Brownlee" , draft-williams-exp-tcp-host-id-opt@ietf.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for draft-williams-exp-tcp-host-id-opt-05

The IESG has completed a review of draft-williams-exp-tcp-host-id-opt-05
consistent with RFC5742.


The IESG recommends that 'Experimental Option for TCP Host
Identification'  NOT be
published as an Experimental RFC.


The IESG has concluded that this document violates IETF procedures about
pervasive monitoring (RFC 7258) and should therefore not be published
without IETF review and IESG approval. This work is related to IETF work
done in the INTAREA WG.


The IESG would also like the RFC-Editor to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-williams-exp-tcp-host-id-opt/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-williams-exp-tcp-host-id-opt/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]
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.

[Ballot comment]
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?

[Ballot comment]
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 a 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?